fvwm-themes-devel — Developing FVWM Themes

Re: Questions using Fvwm-Perl/perlib with my ThemesCenter GUI

[Mikhael G. <mi...@fr...>]

On 04 Dec 2010 10:59:13 +0100, Thomas Funk wrote:
> 
> If I do this (make the program as a module) I can send e.g.
> 'FuncFvwmThemesFresh' or other fvwm functions defined in
> ~/.fvwm/themes-rc file, right? 

Any command that you can send using FvwmConsole (Alt-[Shift-]F12).

Also: fvwm-perllib man

Regards,
Mikhael.

Re: Questions using Fvwm-Perl/perlib with my ThemesCenter GUI

[Thomas F. <t....@we...>]

"Mikhael Goikhman"  wrote:
>The message had a very poor formatting, so I reformatted for clarity.
Sorry, this happened because I pasted it into the answer over IE :-(

>As a module you can at least send commands to fvwm. It is possible to
>also listen to all kinds of fvwm events, and to request information
>about all windows and own module configuration customized by user.
>
>If it is a stand-alone application, it can't control fvwm.
Ah ok, this make sense. So, I will rewrite it to a module.

>I didn't really expect you to implement FVWM::Module::ThemesConfig
>class, this needs some deep understanding and good design. It should
>not really reimplement fvwm-themes-config, but possibly just call it
>when needed and otherwise complement it for GUI purposes. I don't
>have a time for it right now too, but if we come with a good and
>simple design for it, it will be quite easy to implement (possibly>for me).
Yes, I agree with you. It's too complex and my knowledge is not deep enough.

>I still don't know how you implemented your application. If you
>connected it to fvwm-themes-config using its com-mode, then you can
>command fvwm-themes in the sense of switching themes/config, but you
>still can't command fvwm to apply these changes on the fly like the
>existing GUIs in FvwmScript/FvwmForm/FvwmGtk do. So it seems for me
>your application is not interactive at all, and needs some manual
>action from menu (or from other module), like Restart of fvwm or
>"Refresh the current theme" in the menu.
This is why I asked
    >> 3) FvwmScript-ThemeCenter call some Fvwm functions to refresh,
    >> apply, etc the changes. For this I can use the Fvwm-perl module?

Therfore it is important to rewrite the program as a module like you said
    >It can be easier to just pass your commands to fvwm directly and not to
     >FvwmCommand if your application is an fvwm module itself.

>fvwm-perllib is a collection of perl classes that enables you to
>create an fvwm module in several lines of code. If you use
>FVWM::Module::Gtk2, then your application automatically listens to
>both gtk and fvwm events, and you can send commands to fvwm.
If I do this (make the program as a module) I can send e.g. 'FuncFvwmThemesFresh'
or other fvwm functions defined in ~/.fvwm/themes-rc file, right? 

>I hope my answer helped.
Yes, thanks, very much :D

Best Regards,
Thomas
___________________________________________________________
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02

Re: Questions using Fvwm-Perl/perlib with my ThemesCenter GUI

[Mikhael G. <mi...@fr...>]

The message had a very poor formatting, so I reformatted for clarity.

On 01 Dec 2010 12:05:10 +0100, Thomas Funk wrote:
> 
> Hi Mikhael, I red the Fvwm-Perl and Fvwm-perlib documentation as I
> told you in our discussion
> http://sourceforge.net/mailarchive/message.php?msg_name=1732272259.955916.1290902145430.JavaMail.fmail%40mwmweb022

> Now, some basic questions were appeared: 1) What is the advantage to
> program my Fvwm-ThemesCenter as a module?  You wrote
> 
> > maybe I can help you to make it work, either using
> > fvwm-themes-config, or by creating some base perl class, like
> > FVWM::Module::ThemesConfig, so that your FVWM module
> > FvwmThemes[Gtk2]Center could just use it instead (or together
> > with) FVWM::Module::Gtk2.
> 
> I don't use FVWM::Module::Gtk2 nor the program is designed as a
> module.  It's a standalone application (at the moment).

As a module you can at least send commands to fvwm. It is possible to
also listen to all kinds of fvwm events, and to request information
about all windows and own module configuration customized by user.

If it is a stand-alone application, it can't control fvwm.

> 2) Your example FVWM::Module::ThemesConfig - should it be a class
> to replace the functionality of fvwm-themes-config?  If so, then
> it's too much to developing (not enough time). As I wrote, I have
> programmed the client com part which works good enough to simulate
> FvwmScript-ThemeCenter. So, it's easier and results come earlier
> than build all the functionality of fvwm-themes-config in a module. 
> What I can do is to implement the call routines of the client com
> part so, that FVWM::Module::ThemesConfig class can replace it
> later.

I didn't really expect you to implement FVWM::Module::ThemesConfig
class, this needs some deep understanding and good design. It should
not really reimplement fvwm-themes-config, but possibly just call it
when needed and otherwise complement it for GUI purposes. I don't
have a time for it right now too, but if we come with a good and
simple design for it, it will be quite easy to implement (possibly
for me).

I still don't know how you implemented your application. If you
connected it to fvwm-themes-config using its com-mode, then you can
command fvwm-themes in the sense of switching themes/config, but you
still can't command fvwm to apply these changes on the fly like the
existing GUIs in FvwmScript/FvwmForm/FvwmGtk do. So it seems for me
your application is not interactive at all, and needs some manual
action from menu (or from other module), like Restart of fvwm or
"Refresh the current theme" in the menu.

> 3) FvwmScript-ThemeCenter call some Fvwm functions to refresh,
> apply, etc the changes. For this I can use the Fvwm-perl module?

I suppose you meant FvwmPerl module here. It is a good preprocessor,
but it can't help to your application to control fvwm from outside.
You need to use FvwmCommandS (or FvwmSocket/FvwmServer module I
posted recently on the fvwm-workers list). But then you require to
run one or another persistent fvwm module working using sockets just
to make your application work interactively. It can be easier to just
pass your commands to fvwm directly and not to FvwmCommand if your
application is an fvwm module itself.

fvwm-perllib is a collection of perl classes that enables you to
create an fvwm module in several lines of code. If you use
FVWM::Module::Gtk2, then your application automatically listens to
both gtk and fvwm events, and you can send commands to fvwm.

I hope my answer helped.

Regards,
Mikhael.

Questions using Fvwm-Perl/perlib with my ThemesCenter GUI

[Thomas F. <t....@we...>]

Hi Mikhael, I red the Fvwm-Perl and Fvwm-perlib documentation as I told you in our discussion( [http://sourceforge.net/mailarchive/message.php?msg_name=1732272259.955916.1290902145430.JavaMail.fmail%40mwmweb022] ). 
Now, some basic questions were appeared:1) What is the advantage to program my Fvwm-ThemesCenter as a module?     You wrote    >... maybe I can help    >you to make it work, either using fvwm-themes-config, or by creating    >some base perl class, like FVWM::Module::ThemesConfig, so that your    >FVWM module FvwmThemes[Gtk2]Center could just use it instead (or    >together with) FVWM::Module::Gtk2.    I don't use FVWM::Module::Gtk2 nor the program is designed as a module.    It's a standalone application (at the moment). 
2) Your example FVWM::Module::ThemesConfig - should it be a class to replace    the functionality of fvwm-themes-config?    If so, then it's too much to developing (not enough time). As I wrote,    I have programmed the client com part which works good enough to simulate    FvwmScript-ThemeCenter. So, it's easier and results come earlier than build    all the functionality of fvwm-themes-config in a module.    What I can do is to implement the call routines of the client com part so,     that FVWM::Module::ThemesConfig class can replace it later. 
3) FvwmScript-ThemeCenter call some Fvwm functions to refresh, apply, etc the    changes. For this I can use the Fvwm-perl module?
Regards,Thomas
___________________________________________________________
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2

Re: Whether to issue Delete or Close to properly shutdown a window

[Mikhael G. <mi...@ho...>]

Dear Thomas Adam,

My intention was to do this change properly and to discuss it first.

In the past anything that was important for the developers was
implemented. We had hundreds of such decisions and came to pretty
much flexible solutions to satisfy different needs. It can take some
time to understand the needs of each other, but after that initial
step and a willing to make other developers happy too, just doing
"diffs" of commits made us understand new ideas. :)

This is not the best period of the project. I have a family with
everything that this means and am very busy. Noone else has a time
for serious developing as well, it seems.

Working on fvwm-themes is relatively hard (I mean designing the
infrastructure and scripts properly and witting/polishing dozens of
themes and testing everything). This requires a lot of free time,
high discipline and a lot of caring. I still intend to spend some
time on it (at least to fix what I see and make it more up to date).
Maybe it was my error to open a discussion before making commits what
I planned to do.

Thank you for your work. I will understand if someone decides to
leave, although I would not want this to happen.

Regards,
Mikhael.

Re: Whether to issue Delete or Close to properly shutdown a window

[Thomas A. <th...@xt...>]

On Sat, Sep 25, 2010 at 12:32:13AM +0300, Mikhael Goikhman wrote:
> On 24 Sep 2010 21:34:22 +0100, Thomas Adam wrote:
>
> Unfortunately this is not true, Close does not ensure killing or
> ending an application at all. :) The user should still find the
> proper way to end an application.

I'm not talking about the application as "the window plus some other
background process I do not control".  It's the window I am looking at.  If
that window is more than just a single process (i.e., closing this window
doesn't guarantee that it's an application) then I do not mind.  The point
to take away from this [1] is that, regardkess Close guarantees an ordering
of getting rid of a window.

This has nothing to do if the application then continues to run in the
background -- regardless of whether we issued a Delete or a Destroy, that
behaviour to FVWM is undefined.  Again, we did what we could, via Close.

> Moreover, sometimes an application can listen to Delete and decide
> to do nothing. Would Close solve anything? Try "xterm -e su" or
> "xterm -e sudo sh" and then Close.

Not our problem.

> For me this change only reduced a functionality. If a user (like me)
> wants to only properly close applications (this means never try with
> destroying a window) now we make it harder for him. He now can't use
> the window buttons for this, because this will potentially destroy a
> window without even letting him a chance to try something less
> destructive.

It's a bit like asking somebody to chose their favourite fork, from a pile
of forks.  To 99.9% of people, they're a fork, and any one will do, they
won't care.  Save for the .1% of people who will rummage through this pile
of forks, until they find the right one.  But "right" in this context, could
be a fork only with two pronges, and not four.

Do we care that the poor individual who wants a fork with two pronges is now
anguished over this?  No.

> Your change only affected the "default" theme, but all other themes
> still do "Delete" and not "Close". If we are to do something here, it
> should be done properly.

And that's very deliberate:

* There is no proper design for "global" functions to act across all themes,
  where commonalities such as handling signals on windows should happen
  globally and not per-theme.
* To implement such a change is a fairly big change overall.

It was always an oversight not to do this in this way, IMO.

> Previously we used FuncFvwmDelete for this, then a user could define
> "Close" in it in personal theme. But it was changed to just Delete 10
> years ago for the reason described in ChangeLog. I still think that
> using FuncFvwmDelete to delete a window in all themes would be best,
> then it would be easier to change it to Close in one place. I don't
> see this problem described in ChangeLog. Maybe Olivier (if he reads
> such long emails) can comment.

I'm bailing out of any further discussions on this, because:

* At this point, the technical merits simply don't out-weigh user
  expectations;
* There's only so many ways I can add polish to a turd;
* I am not prepared to discard what is a user-expectation issue, solely on
  the merits of a moot technical problem, where "Close" is pretty much safe.

> Also I would like to get one more opinion on this. I don't care if we
> use FuncFvwmClose everywhere in window button (where we used Delete
> until now) as long as I have an easy way to define it to use Delete
> in my personal theme.

Which is a complete non-sequitur to what you're saying.  Of course it would
be, but it would be a pain -- the design of fvwm-themes makes this slightly
rigid to do, but not impossible.

I don't think you're going to get much more opinion on this, because most
users simply aren't going to be aware of the technical points, and more
importantly, I'd bet you any money, they won't care.

I put it to you, Mikhael, try using "Close" as the default -- and close as
many applications as you can, and monitor the fall-out.  I bet you there
won't be a lot, if any, and if there are, you'll be the best bug-hunter
there ever was for applications not closing properly.

If this is the sort of hardship I'm going to endure in the future, over
trivialities, then I'm bailing now from this project before I get burn-out.
I'm simply not prepared to put this much effort into wasting my evenings
talking over technical triffles, when there's much more important things to
do.

I came out of the woodwork to get this done as a favour to one person -- and
you stirred.   I should have just released fvwm-themes.  Until I came along
recently, there'd been no activity, whatsoever.  Heck, even before now, I
was the last person to do anything on this since 2008.

So I'm out.  Good luck to you, Mikhael on this project, and I hope it goes
places for you.

Thomas Funk has some ideas for fvwm-themes which I was mentoring him over,
but no longer can, as I won't be affiliated with this project.  Hence I've
CCed him, and you can now act as fvwm-themes developer.

Thomas Funk:  good luck.  :)  If you're unsuccessful with your ideas, let me
know, and I'll see if there's a different approach you can take.

Mikhael, one last thing.  Take a look here:

http://github.com/ThomasAdam/fvwm-themes/commit/d177e7c655b4f805fea3eeacb72f2d5bd6386a3a

I started to actually make the perl code suck less.  It's not complete, but
it's a start.

Good luck, guys.

-- Thomas Adam

[1] I am struggling to find out how many different ways I can phrase the
same sentence, but it's still interesting...

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: Whether to issue Delete or Close to properly shutdown a window

[Mikhael G. <mi...@ho...>]

On 24 Sep 2010 21:34:22 +0100, Thomas Adam wrote:
> 
> the key thing here -- "potential".  Destroying a window outright
> might mean no side-effects at all, and in the rare-case, it might
> lead to this 100% CPU problem.  But unlikely.

This is what I tried to find. It seems that most of the programs I
encounter (including the several ones not listening to WM_DELETE)
can't be easily destroyed without side effects, sometimes tragical.
If nothing else, an X error is generated on Destroy.

> no guarantee that I'm going to send the right one (c.f. "kill"
> versus "kill -9") -- but more importantly -- *I shouldn't have to*. 
> Thankfully, using "Close" ensures this.

Unfortunately this is not true, Close does not ensure killing or
ending an application at all. :) The user should still find the
proper way to end an application.

Moreover, sometimes an application can listen to Delete and decide
to do nothing. Would Close solve anything? Try "xterm -e su" or
"xterm -e sudo sh" and then Close.

For me this change only reduced a functionality. If a user (like me)
wants to only properly close applications (this means never try with
destroying a window) now we make it harder for him. He now can't use
the window buttons for this, because this will potentially destroy a
window without even letting him a chance to try something less
destructive.

In any case fvwm-themes is designed to be useful for different points
of view, using themes.

Your change only affected the "default" theme, but all other themes
still do "Delete" and not "Close". If we are to do something here, it
should be done properly.

Previously we used FuncFvwmDelete for this, then a user could define
"Close" in it in personal theme. But it was changed to just Delete 10
years ago for the reason described in ChangeLog. I still think that
using FuncFvwmDelete to delete a window in all themes would be best,
then it would be easier to change it to Close in one place. I don't
see this problem described in ChangeLog. Maybe Olivier (if he reads
such long emails) can comment.

Also I would like to get one more opinion on this. I don't care if we
use FuncFvwmClose everywhere in window button (where we used Delete
until now) as long as I have an easy way to define it to use Delete
in my personal theme.

Regards,
Mikhael.

Re: Whether to issue Delete or Close to properly shutdown a window

[Thomas A. <th...@xt...>]

On Fri, Sep 24, 2010 at 11:12:53PM +0300, Mikhael Goikhman wrote:
> On 24 Sep 2010 20:39:58 +0100, Thomas Adam wrote:
> > 
> > On Fri, Sep 24, 2010 at 10:08:52PM +0300, Mikhael Goikhman wrote:
> > > I am not very strong about this issue, although I prefer a less
> > > destructive Delete in buttons than Close. But maybe I miss some
> > > serious use case that caused to such change. What do others think?
> > 
> > This is one of those expose problems which X11 inherently presents
> > to the user.  As a user, I don't care if my window is deleted or
> > destroyed -- just that it goes away when I ask it to close.  The
> > problem there though, is because there's these two very different
> > methods, I start to _have_ to care more if said application
> > suddenly throws a wobbly and sits there IO bound, hosing my machine
> > with 100% CPU.
> > 
> > But that's a side-issue to fvwm-themes appearing to Do The Right
> > Thing (tm) which is ultimately to close my window.  I currently
> > have no wa to do that if the application in question doesn't listen
> > to WM_DELETE, and as a user I am left baffled and confused -- I
> > just want the window to close.
> > 
> > Get fvwm-themes to do The Right Thing (tm) -- at least Close is
> > graceful in trying Delete before Destroy -- and that's the way it
> > should be.  We're not losing out here, we're just ensuring those
> > Brain Dead (tm) applications go away.  Any side-effects coming from
> > a WM_DESTROY aren't FVWM's fault, and legitimately, FVWM is still
> > Doing The Right Thing (tm) -- such observations in Brain Dead
> > Applications (tm) aren't anything to do with us.  After all, we
> > tried to Do The Right Thing (tm) via Close, and that's the best we
> > can and /should/ do.  :)
> 
> I can't agree that the Right Thing is to Destroy by default. I think

It's only Destroy by default if Delete cannot happen.

> the way we had until now was Right. To let user a chance to know this
> window can't be closed easily, only destroyed, leading to potential
> problems (the aplication still continues to run, without a window).

No -- the user doesn't know this, only that they cannot Delete a window.
The user has to know that Destroy has potential side-effects -- and that's
the key thing here -- "potential".  Destroying a window outright might mean
no side-effects at all, and in the rare-case, it might lead to this 100% CPU
problem.  But unlikely.

> It is also not correct that you didn't have a way to close (destroy)
> a window, there are many ways. 1) Menu button / Close. 2) Alt-F4 (or
> Alt-Shift-F4). 3) Click right mouse button on the root, select
> Delete, Close or Destroy. 4) Invoike the long windows operation menu
> on a window, ("More...") and see that Delete is disabled, but Close
> and Destroy are not.

I know that -- but step back and see it from someone who doesn't know the
difference, want to know the difference, or otherwise *care*.  If I click
the "cross" (button 1) on a window titlebar in fvwm-themes, and my window
doesn't close, I am going to get confused.  Indeed, the entire reason why I
made this change was because of this -- a user of fvwm-themes actually
didn't understand why this was.  Not only that, but they were unaware of the
other ways of closing a window.  So I spent thirty minutes teaching them
about X11, the ICCCM, and then getting them to use "Close" on the window.  

The user experience here, is not good.

If I can't Delete my window, I then have a problem:  I need to know how to
close this window.  If I didn't start the application from a console, but
via a menu, I then need to know how to send a signal to the application.
Again, depending on how I do that (even if I know how) there's no guarantee
that I'm going to send the right one (c.f. "kill" versus "kill -9") -- but
more importantly -- *I shouldn't have to*.  Thankfully, using "Close"
ensures this.

Again -- you need to see this from what the user has to do to resolve this
-- versus what FVWM allows you to do.  I don't want to repeat what I
mentioned in my previous email -- but "Close" is the polite thing to do.
Getting the user to jump through hoops because this application doesn't
understand how to Delete itself forces a level of knowledge that's
completely unnecessary.  The window should close.  If that means the
application dies horribly in the background, that's not FVWM's fault -- but
rather a bug in the application.

What have we done here though?   We've minimised what the user has to know
(i.e., hidden the internals of Delete/Destroy) and still closed the window.

That's a good thing.

> For me the current way (before the cvs change) seems Right.

Only from a technical point of view.  But as a user, why do I have to care
by *default* if I am deleting or destroying a window?  I don't -- neither
should I have to if FVWM is always going to Delete the window anyway, and
still close it via Destroy in the rare cases where WM_DELETE isn't honoured.
(Which, BTW, is perfectly valid from the ICCCM's point of view.)

> > I'd bet you no one's going to even notice the change.  :)
> 
> How about the other way? Did the current way present any problems
> to the user; for which applications exactly?

Yes.  See above, clicking the close button on the titlebar didn't do
anything, it was a nop because we tried only to Delete the window, not Close
it (which in this case would have meant Destroy, but I don't care about that
as a user.)

> Maybe the solution is to explicitely list all known programs that
> both do not accept Delete and are ended when any of their window
> is destroyed. For them do: ThisWindow (KnownProgram) Destroy
> (or Close), but for all other programs do Delete, not Destroy.

Special case it?  No chance.  That's just absured, Mikhael.

> Do you have a list of programs that would benefit from Destroy?

No, and to be honest, I wouldn't want to try and come up with a list.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: Whether to issue Delete or Close to properly shutdown a window

[Mikhael G. <mi...@ho...>]

On 24 Sep 2010 20:39:58 +0100, Thomas Adam wrote:
> 
> On Fri, Sep 24, 2010 at 10:08:52PM +0300, Mikhael Goikhman wrote:
> > I am not very strong about this issue, although I prefer a less
> > destructive Delete in buttons than Close. But maybe I miss some
> > serious use case that caused to such change. What do others think?
> 
> This is one of those expose problems which X11 inherently presents
> to the user.  As a user, I don't care if my window is deleted or
> destroyed -- just that it goes away when I ask it to close.  The
> problem there though, is because there's these two very different
> methods, I start to _have_ to care more if said application
> suddenly throws a wobbly and sits there IO bound, hosing my machine
> with 100% CPU.
> 
> But that's a side-issue to fvwm-themes appearing to Do The Right
> Thing (tm) which is ultimately to close my window.  I currently
> have no wa to do that if the application in question doesn't listen
> to WM_DELETE, and as a user I am left baffled and confused -- I
> just want the window to close.
> 
> Get fvwm-themes to do The Right Thing (tm) -- at least Close is
> graceful in trying Delete before Destroy -- and that's the way it
> should be.  We're not losing out here, we're just ensuring those
> Brain Dead (tm) applications go away.  Any side-effects coming from
> a WM_DESTROY aren't FVWM's fault, and legitimately, FVWM is still
> Doing The Right Thing (tm) -- such observations in Brain Dead
> Applications (tm) aren't anything to do with us.  After all, we
> tried to Do The Right Thing (tm) via Close, and that's the best we
> can and /should/ do.  :)

I can't agree that the Right Thing is to Destroy by default. I think
the way we had until now was Right. To let user a chance to know this
window can't be closed easily, only destroyed, leading to potential
problems (the aplication still continues to run, without a window).

It is also not correct that you didn't have a way to close (destroy)
a window, there are many ways. 1) Menu button / Close. 2) Alt-F4 (or
Alt-Shift-F4). 3) Click right mouse button on the root, select
Delete, Close or Destroy. 4) Invoike the long windows operation menu
on a window, ("More...") and see that Delete is disabled, but Close
and Destroy are not.

For me the current way (before the cvs change) seems Right.

> I'd bet you no one's going to even notice the change.  :)

How about the other way? Did the current way present any problems
to the user; for which applications exactly?

Maybe the solution is to explicitely list all known programs that
both do not accept Delete and are ended when any of their window
is destroyed. For them do: ThisWindow (KnownProgram) Destroy
(or Close), but for all other programs do Delete, not Destroy.

Do you have a list of programs that would benefit from Destroy?

Regards,
Mikhael.

Re: Whether to issue Delete or Close to properly shutdown a window

[Thomas A. <th...@xt...>]

On Fri, Sep 24, 2010 at 10:08:52PM +0300, Mikhael Goikhman wrote:
> I am not very strong about this issue, although I prefer a less
> destructive Delete in buttons than Close. But maybe I miss some
> serious use case that caused to such change. What do others think?

This is one of those expose problems which X11 inherently presents to the
user.  As a user, I don't care if my window is deleted or destroyed -- just
that it goes away when I ask it to close.  The problem there though, is
because there's these two very different methods, I start to _have_ to care
more if said application suddenly throws a wobbly and sits there IO bound,
hosing my machine with 100% CPU.  

But that's a side-issue to fvwm-themes appearing to Do The Right Thing (tm)
which is ultimately to close my window.  I currently have no wa to do that
if the application in question doesn't listen to WM_DELETE, and as a user I
am left baffled and confused -- I just want the window to close.

Get fvwm-themes to do The Right Thing (tm) -- at least Close is graceful in
trying Delete before Destroy -- and that's the way it should be.  We're not
losing out here, we're just ensuring those Brain Dead (tm) applications go
away.  Any side-effects coming from a WM_DESTROY aren't FVWM's fault, and
legitimately, FVWM is still Doing The Right Thing (tm) -- such observations
in Brain Dead Applications (tm) aren't anything to do with us.  After all,
we tried to Do The Right Thing (tm) via Close, and that's the best we can
and /should/ do.  :)

I'd bet you no one's going to even notice the change.  :)

I think with all these trademarks I'm issuing here, I could make a nice tid
sum of money on the side... ;)

-- Thomas Adam


"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Whether to issue Delete or Close to properly shutdown a window

[Mikhael G. <mi...@ho...>]

I'd like to discuss one small issue. Until now double click on the
menu button (usually on the left) and a click on the "X" button
(usually on the right) did "Delete", but recently it was changed to
"Close" in cvs.

The reason why it did "Delete" by default was this. The applications
that do not implement the delete-window protocol may get easily
confused when their window is destroyed, just like the applications
that support this protocol. Try to destroy a window of firefox, this
can lead to a pretty serious mess, not something to allow by default.

So I would rather not close a window at all than just destroy it. I
remember that some application (can't find which now) even started to
use 100% of CPU when its window was destroyed. There are more
examples of misbehaviour, for example ghostscript. You can destroy
its window, but this does not finish the utility, it will still
accept commands, but will be confused and throw X errors.

For a similar reason in the early versions of fvwm-themes we had 2
entries in the short windows-operations menu (Delete and Destroy). So
that the user could decide whether to destroy a window (often
problematic) or not. Then it was replaced by a single Close, but this
is still less a problem, because a user can see what he runs when he
selects the operation. Next time he will know not to select "Close"
on this window, but to try something else. Here with the buttons the
user does not know what is executed, and by clicking he just wants to
end an application, not to get a mess.

I am not very strong about this issue, although I prefer a less
destructive Delete in buttons than Close. But maybe I miss some
serious use case that caused to such change. What do others think?

Regards,
Mikhael.

Re: Releasing fvwm-themes CVS -> fvwm-themes-0.7.1

[Thomas A. <th...@xt...>]

On 5 September 2010 18:55, Mikhael Goikhman <mi...@ho...> wrote:
> I feel that we should release a new version. But since I never had a
> time to seriously develop it in the last years and I don't currently
> even run the latest cvs versions (but still pretty recent), and I see
> small bugs, I can't yet fully comment on it.

What bugs?  I updated CVS to get rid of numerous warning a few years
ago -- which today have still stood the test of time.

Even the transparent theme works well, for instance.

-- Thomas Adam

Re: Releasing fvwm-themes CVS -> fvwm-themes-0.7.1

[Mikhael G. <mi...@ho...>]

On 05 Sep 2010 14:51:58 +0100, Thomas Adam wrote:
> 
> I'm wondering if there's any fvwm-themes users out there still who'd
> notice this, so I will ask on the off-chance.

I think the lists work and have several dozens of subscribers.

> I'm satisfied with my improvements to the CVS version of fvwm-themes
> that we can do a new stable release.
> 
> How would people here feel about that?

I feel that we should release a new version. But since I never had a
time to seriously develop it in the last years and I don't currently
even run the latest cvs versions (but still pretty recent), and I see
small bugs, I can't yet fully comment on it.

I will try to spend one day on fvwm-themes next week and then I will
hopefully reply on the devel list. Please remind me if I don't.

Regards,
Mikhael.

Releasing fvwm-themes CVS -> fvwm-themes-0.7.1

[Thomas A. <th...@xt...>]

All,

I'm wondering if there's any fvwm-themes users out there still who'd
notice this, so I will ask on the off-chance.

I'm satisfied with my improvements to the CVS version of fvwm-themes
that we can do a new stable release.

How would people here feel about that?

Kindly,

-- Thomas Adam

Merging fvwm-crystal with fvwm-themes?

[Thomas A. <th...@xt...>]

Hello all,

[ Sorry for the cross-posting, but on this occasion, I feel it's justified. ]

I am going to suggest something perhaps controversial, but ultimately in the
long-run more beneficial to the FVWM community -- at least I think so,
anyway.

How would people feel about merging fvwm-crystal into fvwm-themes?  I see
this as being a good thing -- bringing existing themes together into one
project means a greater amount of consolidation.  Granted, there would have
to be quite a bit of re-engineering, but I think it's doable -- the python
menu would need to be rewritten to use perllib though.

Consolidation of both these projects -- and specifically -- fvwm-crystal
into fvwm-themes means they're both using the same design.  Whilst
fvwm-crystal is OK, it's more or less reinvented the wheel with what
fvwm-themes provides, and I feel this is not only a waste, but a lot more
work to maintain two very similar projects.

This would be a great way for people to contribute to FVWM.  I would welcome
some initial thoughts on this, and am happy to mentor/help anyone who wants
to attempt this.  Whilst I am busy on FVWM itself, this would be a great
time to consider this, perhaps in time for the eventual 2.6.0 release of
FVWM.

Any questions, feel free to ask.

Kindly,

-- Thomas Adam

Off-topic: Translators wanted for opensource

[Samuel M. (Groenkloof) <sa...@tr...>]

G'day everyone

I noticed that this project is quite active on Source Forge, and for 
that reason I'd like to tell you about our translation project.  I'm 
also hoping that some of you might be able to help us with translations 
or ideas.

The project is called Decathlon because we want to encourage people who 
feel passionate about their language to translate up to ten or more 
opensource programs into their languages in 2008.  This year, we limit 
our selection of translated programs to applications aimed at end-users, 
and preferably programs that run on multiple platforms.

All translations are done in our web-based translations system, Pootle. 
  The value of Pootle is that a team of translators can work together on 
a single file.  Pootle also has quality checking features, to ensure 
that translations don't break the software they are used in.   Pootle 
requires the Gettext PO format, but we can convert certain other formats 
to and from PO.

More information about the Decathlon project can be found here:
http://translate.sourceforge.net/wiki/decathlon/mainpage

Our Pootle server is here:
http://pootle.locamotion.org/

I look forward to hearing from anyone who is interested.  You are 
welcome to pass this e-mail on to anyone you think may be interested.

Sincerely

Samuel Murray
Decathlon project leader

Re: How to continue fvwm-themes development

[Mikhael G. <mi...@ho...>]

On 25 Mar 2008 01:42:40 +0000, Thomas Adam wrote:
> 
> On 10/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
> >  Now, the main question is whether we may only discuss things or actually
> >  implement them too.
> 
> OK.  I hope I have this right, was a little hairy, so fingers crossed.
> 
> I've pushed a series of commits to the fvwm-themes CVS repository on
> SF which is my first set of "phase 1" patches.  These do nothing more
> than a sweep and clean through each theme, updating existing files for
> deprecated options, replacing those options with newer ones where
> necessary.  This should alleviate any clutter in terms of deprecation
> warnings from FVWM.
> 
> Based on FVWM 2.5.25 (and beyond.)

I just got a time to look at it (I'm pretty busy as usual).

Your changes look good.

> Tomorrow's job will be a perl code review, as stated in this thread.
> 
> Then I will look at making a list of options in current FVWM which
> fvwm-themes could benefit from using in some or all of its themes.
> 
> It's 01:42am.  I hope I've not buggered anything up.  If so, do let me know.

Please continue to make changes as planned. It is ok if something is not
ideal, everything may be fixed later.

Possibly I will be able to commit again at some point, but not right now.

Regards,
Mikhael.

Re: How to continue fvwm-themes development

[Thomas A. <tho...@gm...>]

On 10/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
>  Now, the main question is whether we may only discuss things or actually
>  implement them too.

OK.  I hope I have this right, was a little hairy, so fingers crossed.

I've pushed a series of commits to the fvwm-themes CVS repository on
SF which is my first set of "phase 1" patches.  These do nothing more
than a sweep and clean through each theme, updating existing files for
deprecated options, replacing those options with newer ones where
necessary.  This should alleviate any clutter in terms of deprecation
warnings from FVWM.

Based on FVWM 2.5.25 (and beyond.)

Tomorrow's job will be a perl code review, as stated in this thread.

Then I will look at making a list of options in current FVWM which
fvwm-themes could benefit from using in some or all of its themes.

It's 01:42am.  I hope I've not buggered anything up.  If so, do let me know.

-- Thomas Adam

Re: How to continue fvwm-themes development

[Mikhael G. <mi...@ho...>]

On 09 Mar 2008 16:48:10 +0000, Thomas Adam wrote:
> 
> On 09/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
> >  There is a need to revise all numerous themes. If someone uses a theme,
> >  there is no reason to remove it. But if noone uses some theme and noone
> >  wants to maintain it, it just takes a disk space of the users and
> >  complicates the development. But I am not aware about any way to know
> >  who uses which theme, so someone should just take the decision.
> 
> I fail to see why we should remove themes - augmenting existing themes
> and adding new ones (should there ever be any ;)) would be my
> preferred route.

I think I answered above. There are naturally millions of combinations of
different theme components, some of which don't work together because it
is just impossible and some because of inaccurate configs. I needed to
spend a lot of time trying different combinations before each release,
and it should be tried with different tools installed and different fvwm
versions and so on. So less unused themes means less problems.

> >  There is some long perl code in the scripts not written by me that I
> >  never had a time to verify. I am not sure whether it is up to date.
> 
> Do you have some pointers to these?  I don't mind taking a look.

The scripts to verify are in bin/ directory of course.

> >  Some options (support for GNOME 1 or KDE 2) should be removed or updated.
> 
> Removed, and update to GNOME2.

Well, I don't use GNOME or KDE, so someone else should do this.

> >  Integration with the latest fvwm and wm-icons should be updated.
> 
> This is a major undertaking actually.  Having looked through almost
> every file in fvwm-themes, the state of them isn't too bad with
> respect to current FVWM options.   And can we be clear here -- when we
> say current, I hope we mean FVWM 2.5.X.  Yes, there are some options
> in fvwm-themes which will need to be removed and replaced with
> something more current.  Again, I don't mind doing that either.

Feel free to. Discuss if in doubt.

> >  I would like to hear who can and wants to do what. People with write
> >  permissions may just commit what they think is good for fvwm-themes.
> 
> Well, if it were me, I would say:  take the existing state of
> fvwm-themes, and update it where necessary to support features with
> FVWM 2.5.25.  Maintain some backwards compatibility where appropriate,
> but try where possible to flaunt FVWM 2.5.25.  This might be
> controversial, I know, but then I really don't know of anyone using
> 2.4.X these days.

This is not really a problem. Like the homepage says (someone should
redesign it BTW), we don't support 2.4.x since 0.7.0.

> With such an "infrastructure" in place, adding in new themes might be
> more manageable.
> 
> Also, have you considered why fvwm-crystal [1] is perhaps more
> ""popular"" than fvwm-themes?  The features it has mimick almost in
> their entirety fvwm-themes (not uncommon, actually, I see many people
> reinvent the whee l with their configs) but it does have support for
> some nice things -- transparency notwithstanding, so maybe some ideas
> can be used from there?  That seems to be what the majority of people
> want these days... shrugs.  I'm more an MWM man myself....

More FVWM based projects is always good. Our home page links to most of
them. I am not sure uniting these projects is very practical (the accents
put are different). I think all FVWM based projects have a problem of
developers/designers and in some sense users. As for sharing good ideas
it is always good.

Now, the main question is whether we may only discuss things or actually
implement them too.

Regards,
Mikhael.

Re: How to continue fvwm-themes development

[Klaus H. <k....@fe...>]

Thomas Adam wrote:

> Ah, one of the *BSDs?  You're screwed then.  ;)  You will need to most

I do not think I am screwed for using NetBSD :-)

> likely compile FVWM yourself, since last I checked most if not all the
> BSDs ship FVWM 2.4.X, and worse *yet* I believe that OpenBSD still
> ships FVWM 2.2.X

There are packages for fvwm (2.4.20), fvwm-devel (2.5.25) and fvwm-themes
(0.6.2) in pkgsrc.

> Or have I somehow missed what it is you're trying to tell us?

You wrote

  > but try where possible to flaunt FVWM 2.5.25.  This might be
  > controversial, I know, but then I really don't know of anyone using
  > 2.4.X these days.

There _are_ people using fvwm 2.4.20, probably because it is the stable
version.

ciao
     Klaus

Re: How to continue fvwm-themes development

[Thomas A. <tho...@gm...>]

On 09/03/2008, Klaus Heinz <k....@fe...> wrote:
>   $ pkg_info -e fvwm
>   fvwm-2.4.20

Ah, one of the *BSDs?  You're screwed then.  ;)  You will need to most
likely compile FVWM yourself, since last I checked most if not all the
BSDs ship FVWM 2.4.X, and worse *yet* I believe that OpenBSD still
ships FVWM 2.2.X

>  Last time I looked (a few minutes ago), I saw this
>
>   Latest Stable Release:        2.4.20
>   Latest Unstable Release:      2.5.25
>
>  on the front page of www.fvwm.org.

Yes that's right.  I fail to see what the problem is.  If you're using
fvwm-themes 0.7.0 and you're using FVWM 2.4.X, you'll run into issues,
in which case you want fvwm-themes 0.6.2 although in all honesty, you
really should just use FVWM 2.5.25 with fvwm-themes 0,7.0

Or have I somehow missed what it is you're trying to tell us?

-- Thomas Adam

Re: How to continue fvwm-themes development

[Klaus H. <k....@fe...>]

 [ I am just an innocent spectator who happened to stumble over a small
   issue in the configure script. ]

Thomas Adam wrote:

> FVWM 2.5.25.  Maintain some backwards compatibility where appropriate,
> but try where possible to flaunt FVWM 2.5.25.  This might be
> controversial, I know, but then I really don't know of anyone using
> 2.4.X these days.

  $ pkg_info -e fvwm
  fvwm-2.4.20

Last time I looked (a few minutes ago), I saw this

  Latest Stable Release:    	2.4.20  	
  Latest Unstable Release:   	2.5.25 	

on the front page of www.fvwm.org.

ciao
     Klaus

Re: How to continue fvwm-themes development

[Thomas A. <tho...@gm...>]

On 09/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
>  There is a need to revise all numerous themes. If someone uses a theme,
>  there is no reason to remove it. But if noone uses some theme and noone
>  wants to maintain it, it just takes a disk space of the users and
>  complicates the development. But I am not aware about any way to know
>  who uses which theme, so someone should just take the decision.

I fail to see why we should remove themes - augmenting existing themes
and adding new ones (should there ever be any ;)) would be my
preferred route.

>  There is some long perl code in the scripts not written by me that I
>  never had a time to verify. I am not sure whether it is up to date.

Do you have some pointers to these?  I don't mind taking a look.

>  Some options (support for GNOME 1 or KDE 2) should be removed or updated.

Removed, and update to GNOME2.

>  Integration with the latest fvwm and wm-icons should be updated.

This is a major undertaking actually.  Having looked through almost
every file in fvwm-themes, the state of them isn't too bad with
respect to current FVWM options.   And can we be clear here -- when we
say current, I hope we mean FVWM 2.5.X.  Yes, there are some options
in fvwm-themes which will need to be removed and replaced with
something more current.  Again, I don't mind doing that either.

>  I would like to hear who can and wants to do what. People with write
>  permissions may just commit what they think is good for fvwm-themes.

Well, if it were me, I would say:  take the existing state of
fvwm-themes, and update it where necessary to support features with
FVWM 2.5.25.  Maintain some backwards compatibility where appropriate,
but try where possible to flaunt FVWM 2.5.25.  This might be
controversial, I know, but then I really don't know of anyone using
2.4.X these days.

With such an "infrastructure" in place, adding in new themes might be
more manageable.

Also, have you considered why fvwm-crystal [1] is perhaps more
""popular"" than fvwm-themes?  The features it has mimick almost in
their entirety fvwm-themes (not uncommon, actually, I see many people
reinvent the whee l with their configs) but it does have support for
some nice things -- transparency notwithstanding, so maybe some ideas
can be used from there?  That seems to be what the majority of people
want these days... shrugs.  I'm more an MWM man myself....

-- Thomas Adam

[1]  http://fvwm-crystal.org/

How to continue fvwm-themes development

[Mikhael G. <mi...@ho...>]

First, I believe there are fvwm-themes users. I use it and don't see
myself using something else. Probably there are others feeling similarly.
So it needs to be developed.

Bringing some driving forces would really help. I spend full time on my
day-to-day work and family, but I would be able to discuss new ideas.

fvwm-themes is probably too configurable in some places and not
configurable enough in others. This should be discussed and improved.

There is a need to revise all numerous themes. If someone uses a theme,
there is no reason to remove it. But if noone uses some theme and noone
wants to maintain it, it just takes a disk space of the users and
complicates the development. But I am not aware about any way to know
who uses which theme, so someone should just take the decision.

There is some long perl code in the scripts not written by me that I
never had a time to verify. I am not sure whether it is up to date.

Some options (support for GNOME 1 or KDE 2) should be removed or updated.

Integration with the latest fvwm and wm-icons should be updated.

There are some open tasks in the SourceForge task manager. Some problems
are serious, including failure of ./configure. They should be solved.

New good features would be nice to have.

Packagers for Fedora and Debian distributions are needed.

Some advocacy is needed.

I would like to hear who can and wants to do what. People with write
permissions may just commit what they think is good for fvwm-themes.

Regards,
Mikhael.

Re: Continuing to develop fvwm-themes

[Thomas A. <tho...@gm...>]

On 04/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
> On 04 Mar 2008 14:35:23 +0000, Thomas Adam wrote:
>  >
>  > [ Dropped fvwm-themes-users from the Cc list, per request. ]
>  >
>  > On 04/03/2008, Mikhael Goikhman <mi...@ho...> wrote:
>  > > Just to clarify, I spoke about help with maintaining all numerous themes,
>  > >  scripts and configurations. fvwm-themes is complex enough, so probably
>  > >  only me and Olivier understand it wholly. But anyone may learn it too.
>  >
>  > Right -- and this was the assumption I was also under.  I've been
>  > tracking FVWM-themes for a very long time, and know a lot about its
>  > internals.  I also know Perl well, for my sins.
>  >
>  > >  Alex and 6 more people already have write permissions in cvs. I may add
>  > >  Thomas as a project developer with needed permissions after he creates a
>  > >  SourceForge account and tells me the unix name. Waiting for good commits.
>  >
>  > Well, I've created an account with a username of:
>  >
>  > thomasadam
>
>  I added it. You may freely update fvwm-themes/ and fvwm-themes-web/.

Confirmed.  Thank you.

>  > Beyond that I don't know anything about how to use sourceforge.  I
>  > presume this is what you needed to know?
>
>  I think you may access all needed info from your SourceForge page where
>  you will see all your projects as well.

Yep - now that I have a project assigned to me, everything looks
straightforward enough.

>  > To get this started, what is it that needs doing?  FVWM-themes 0.70
>  > has been about for ages; are there any plans to release what's
>  > currently in CVS?
>
>  The plans were to continue to update and improve everything and keep
>  fvwm-themes synchronized with fvwm features. Basically fvwm-themes was
>  developed by me and Olivier and we implemented what we saw the most
>  useful for ourselves and possibly for others. I believe it slowed down
>  because we were too busy and it was not too fun anymore, and possibly
>  because we reached some happeness with the existing code.

That's understandable.  There's been a considerable additions to FVWM
which fvwm-themes just doesn't reflect but that's expected.

>  How can it be continued? Well, one of the scenarios is similar to what
>  was done with wm-icons that was not developed for years. Mikko Heiskanen
>  came and told me he wants to add several nice png-based icon-sets and to
>  make some more improvements (including a completely new web page), but he
>  needs an assistence with this. I have a time to assist. So we cooked
>  together the wm-icons-0.4.0 release.

I remember Mikko asking me about this - I'm pleased it came to fruition.

>  I'll write another email on the plans. The Olivier comments are welcome.

OK, I shall await that,  Thanks.

-- Thomas Adam