Re: Do we still need color-limit/visual options in fvwm?

[Thomas Funk]

On 05/07/2016 12:40 PM, Thomas Adam wrote:

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?


I would suggest to swap out the functionality into a module like bidi but
don't know how hard it is to do that ...

Does removing color limiting affecting things like remote connections?

If so, it shouldn't be removed.

Best,
Thomas

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Some advices about the new static website

[Thomas Funk]

Hi Jaimos,

I've visited the website again and I only can say - WOW! Great work!
The Header 'inside' the window looks pretty cool :-)
Also your other changes (colors, formatings, ...)

One idea came to my mind after clicking Support->FVWM Forums ...
Is it possible to show the forums inside the window? ^^

Best,
Thomas

--
"Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe."   --   Albert Einstein

Re: Some advices about the new static website

[Thomas Funk]

On 04/09/2016 01:31 AM, Dan Espen wrote:

We don't have stable and unstable anymore so references to
stable and unstable should be removed.


Yes you're right and I know this but since the update to static these
html docs with linked keywords are available from unstable only [1].
Therefore I said 'unstable'. Okay, wasn't the right word but in quotes.

-- Thomas --

[1] http://fvwm.org/doc/unstable/index.html
--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Some advices about the new static website

[Thomas Funk]

On 04/09/2016 12:53 AM, Jaimos Skriletz wrote:

​I believe I know which ones you were talking about.​
​Was this the alphabetical ​list of terms that linked to their location
inside the man pages. It was a nice set of links as it made looking
for some things easier.


Yes and the links inside fvwm manpage(s) e.g. SloppyFocus 12x or
WindowShadeSteps (5x) ...


​Right now the only links are at the bottom of each manpage (with a
link from the top) or just searching the man page for key words. (I
guess for the time I could take the links at the bottom of each
manpage put them nicely located at ​http://fvwm.org/documentation/manpages/)
as this is a copy paste, but I don't think these are the links you
were talking about).


Nope. But back links are very comfortable on the right place ;)


It may be nice to get something like that back up, but with the
conversion of the manpages to markdown the current scripts will be
outdated, so after that conversion is done, I will go checkout how
to get such a set of links setup. Provided they only linked to headings
that will be generated by markdown this should be fairly straight
forward to script.


That would be great :)

-- Thomas --

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Some advices about the new static website

[Thomas Funk]

On 04/08/2016 11:41 PM, Thomas Adam wrote:

Maybe, but again, there'll only ever be one set of man pages to reflect when
releases happen.  Since I've put in place a means of generating them from
markdown (and have yet to receive offers on help with that), I'll see what
happens when I have time to look at this.


I would but currently too busy.


I'm not clear what you're referring to with "linking" either.


I meant the links in
http://fvwm.org/doc/unstable/fvwm/fvwm.man.html

And again the html docs under http://fvwm.org/doc/unstable are/were the
same as under http://fvwm.org/doc/stable since ages.


--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Fwd: Re: Some advices about the new static website

[Thomas Funk]

On 04/08/2016 10:47 PM, Jaimos Skriletz wrote:

On Fri, Apr 8, 2016 at 1:44 PM, Thomas Funk <t.f...@web.de 
<mailto:t.f...@web.de>>wrote:
​The "logo" is now the menu entry, so instead of just saying "FVWM" I
put the logo in its place. The logo except for looks works just as
any other entry in the menu. So what you see is expected.​


Hmmm ... it isn't clearly enough that a menu is behind the logo. In
general the logo is the way back to the home page.


It's a pitty that you've removed the upper frame/part/block with the
heading. Or is it disappear and should normally available? That would
explain the logo on the 'FVWM' menu point o_O


​The new design was to instead of just have the header wrapped in a
window frame is to have the whole site be wrapped in a window frame.
So I took away the top window and wrapped every page in a full window
frame. The title is now in the titlebar of the window frame.

I could add another header above it, but I though it was mostly used
space on the page that isn't needed. All the header did was repeat
the title of the page another place in bigger letters. But I could
easily add it back and then have two windows, a title window and a
main content window.


Why adding the top page in the window, too? Above of the menu part.
But a little bit smaller (~90%) in the height. Also the logo.

The title is very nice. I would use 'The Offical FVWM Home Page' the
whole time if the top page added again ;)



Another point which looks a little bit weird are the framed words in e.g.
manpages or the Mailing Lists page. Probably these text pieces were
Monospace before conversion? Is it possible to remove the frame?


​The sites are generated by markdown which generates in-line code and
code blocks. I have been thinking about the formatting of these, but
I like them being seperate from noral text. The code blocks should be
used for things people would type into a config file, terminal, etc.

I do think some styles on these code blocks need to be updated (and
maybe some work/policy about what should be put in code blocks and
what shouldn't be). The FAQ has been updated and makes better use of
them, but I have only applied that to the FAQ page. In my TODO list
is to try to make use of code blocks more uniform.


I don't mean the code blocks. For example Mailing Lists page 'subscribe'
or '*-request'.


I'm open for suggestions to make it look nicer (I like the borders
myself). Other common examples are using a slightly different color
background or some other method to highlight code blocks vs descriptions.


I like the colors. This is FVWM everybody knows ^^



And in the end one typo:
- Downloads: 'The latest sable release' ;)


​Thanks, I like easy fixes.


You're welcome ^^



I'll add them, My only concern is ensure they are useful so we don't
put to much noise in trying to direct users to useful sties to help
them with fvwm.


Thanks :)

Re: Some advices about the new static website

[Thomas Funk]

On 04/08/2016 11:08 PM, Thomas Adam wrote:

On Fri, Apr 08, 2016 at 09:44:48PM +0200, Thomas Funk wrote:

What about the perlib pages and the ... uhm ... 'unstable' documentation
pages (http://fvwm.org/doc/unstable/index.html)? Will they appear again
in the future?


perllib maybe (althought woefully out of date, and it's on my TODO list to
look at).


I could help you if you like as I did much inside Fvwm-Nightshade with
perllib.


 As for unstable man pages, no.  There's no such thing any more, and
hasn't been for a long time now.


'unstable' was only used as example. As I remember the same pages exists
on 'stable', too. But it would be a shame to lost those pages. Also Dan
did much work on the linking on the FVWM page.


Btw I have some website links for our 'Links' page:

History
---
In the beginning was ...
http://edulinux.homeunix.org/fvwm/user_enumerate.html


Really?  That shouldn't resolve at all.  You mean:

http://www.xteddy.org/fvwm/user_enumerate.html


Yes, indeed :)


--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Some advices about the new static website

[Thomas Funk]

Hi Jaimos,

until your last commit I took a look over the new static pages on fvwm.org
and want to tell you what I've noticed:

Cool feature with the window buttons (maximize, shade/unshade) and the
logo behind B) :)

But the small logo (left upper corner) overlaps the main menu 'FVWM' :(
Used browser: Chromium 48.0.2564.116

It's a pitty that you've removed the upper frame/part/block with the
heading. Or is it disappear and should normally available? That would
explain the logo on the 'FVWM' menu point o_O

Another point which looks a little bit weird are the framed words in e.g.
manpages or the Mailing Lists page. Probably these text pieces were
Monospace before conversion? Is it possible to remove the frame?

Then the text blocks right of the screenshots. It would look be better
if there's a distance to the upper line. Likewise the same gap as between
screenshot and line.

What about the perlib pages and the ... uhm ... 'unstable' documentation
pages (http://fvwm.org/doc/unstable/index.html)? Will they appear again
in the future?

And in the end one typo:
- Downloads: 'The latest sable release' ;)

A very big thanks for your good work and I hope I haven't hurt you with
these advices 0_0 ...

Best,
Thomas

Btw I have some website links for our 'Links' page:

History
---
In the beginning was ...
http://edulinux.homeunix.org/fvwm/user_enumerate.html

Other FVWM-related sites

How Styles are Applied
http://linuxgazette.net/127/adam.html

Fvwm and Session Management
http://linuxgazette.net/100/adam.html
(perhaps a little bit outdated but anyway interesting)


--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam" <tho...@fvwm.org> wrote:
> On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> > I think we should. It's better to have such in the documentation so no
> > questions appears anymore ;)
> > 
> > I can add it to the document, no prob.
> 
> I've added a few words about this, without making this a rule, which
> hopefully people will follow.

That's fine, thanks.

> 
> -- 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: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam" <tho...@fvwm.org> wrote:
> On Fri, Mar 25, 2016 at 03:30:03AM +0100, Thomas Funk wrote:
> > One point:
> > Should we use for development branches a special nomination like 
> > feature_xy, fix_abc?
> > Or only a README which describes the feature/fix?
> 
> I don't think that's necessary.  Typically, you have this pattern:
> 
> initials/rough-branch-description
> 
> Which denotes---by the initials---who's mainly working on the branch,
> so for example:
> 
> ta/fix-clang-warnings
> 
> Should denote that I am working on a branch which fixes warnings from
> Clang.  Similarly, there's also "git branch --edit-description" which
> can further annotate a branch, usually more helpful when issuing
> pull-requests.
> 
> Perhaps in a more wider-context, if a branch ends up not having a
> prefix, it might mean more than one person is working on it.
> 
> But I don't think this really needs documenting.

I think we should. It's better to have such in the documentation so no
questions appears anymore ;)

I can add it to the document, no prob.

> 
> > To think about this point: 
> > http://nvie.com/posts/a-successful-git-branching-model/
> 
> Hmm.  I have always been against this design---this is what lead to the
> whole git-flow set of tooling, which completely locks you in to one way
> of working.  We really do not need anything as complicated as that.

Ok.

> 
> -- 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.)
> 
> 

Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam"  wrote:
> I was thinking along the lines of this diff:
> 
> https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch
> 
> Which you can view rendered here:
> 
> https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md
> 
> What do others think?

Thanks Thomas! It is really good and detailed instruction.

One point:
Should we use for development branches a special nomination like feature_xy, 
fix_abc?
Or only a README which describes the feature/fix?

To think about this point: 
http://nvie.com/posts/a-successful-git-branching-model/

-- Thomas --

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Thomas Adam tho...@fvwm.org wrote:
 On 25 July 2012 18:38, Thomas Funk t.f...@web.de wrote:
 Dan Espen wrote:
 Thomas Adam made some comments about using FvwmPerl.  Is that resolved?
 No -- and as such, until it starts to use perllib and/or FvwmPerl,
 it's not ready.  There is *no* reason why we wouldn't dog-food our own
 implementation of interfacing to FVWM, other than the individual
 developer concerned didn't understand it.  We _have_ a framework to do
 all of the functionality the code currently uses; it's high-time we
 use it.

 I've fixed all what Thomas suggested except the part to do the complete
 stuff with the perllib framework. That needs a little bit more time.
 But that's the entirety of this file, as far as I am concerned.  A
 pretty important part, too.

 I hope it is ok for Thomas that you want to commit it because it's only
 an interim solution.
 Until this is fixed, I would rather this wasn't put in CVS at all.  As
 I've mentioned my time is limited, but if I have to roll up my sleeves
 and take responsibility for this, I don't mind.  I'd rather not
 though, but either way, someone should let me know if I have to.

 Kindly,

 -- Thomas Adam

I would first like to say that it takes some time to understand your
writing. I am not a native English, so please forgive me if I haven't
understood it completely/correctly.

I am willing to do the job of rewriting it but I need help. If you could
take some of your spare time to give me hints and answer questions fairly
would be fine.

What I want to say is, that i want an open, honest and constructive
discussion about the programming and functionality of the module and not
RTFM - I do this every time before I asking.

So if you're willing to be a mentor in a sense I am ready to
programming it.

Kindly,

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/23 Thomas Adam tho...@fvwm.org:
 Don't destroy the same menu you're about to (re)create.
But if I don't destroy it it will be added again and again to
the root menu every time I pop it up ...

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/23 Thomas Funk t.funk...@googlemail.com:
 2012/7/23 Thomas Adam tho...@fvwm.org:
 Don't destroy the same menu you're about to (re)create.
 But if I don't destroy it it will be added again and again to
 the root menu every time I pop it up ...
I've tested it on my VM and you're right! Is this because the
menu will built only once due to DynamicPopupAction?

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Thomas Adam tho...@fvwm.org wrote:
 package Test;
 Will need better namespacing.
changed it to package MenuConfig;

 use File::Basename;
 use strict;
 use warnings;
added

 my $selected = `fvwm-menu-desktop --get-menus selected`;
 How long do these commands take to run in backticks?  If long, 
perhaps use

 IPC::Run?
marginal:
Backticks:
all menus: 0.63 s
selected menus: 0.29 s
both menus: 0.92 s

IPC::Run:
all menus: 0.62 s
all menus: 0.28 s
both menus: 0.90 s

Furthermore IPC::Run isn't installed by default and in older distributions
not available only on CPAN.

 my ($filename, $directories, $suffix) = fileparse($path, 
qr/\.[^.]*/);

 Why qr?
From perldoc: ... qr matched against the end of the $filename. The
matching portion is removed and becomes the $suffix.

 push (@{$all_menus{$directories}{$i}}, $filename);
 push (@{$all_menus{$directories}{$i}}, $name);
 push (@{$all_menus{$directories}{$i}}, off);
 push (@{...}, ($foo, $bar, hello));
changed

 if (exists $selected__menus{$directories}) {
  foreach my $hit (@{$selected__menus{$directories}}) {
 Better:

 foreach my $foo (...)
 {
 next if !defined $bar;
 ...
 }
changed

 You need to use FvwmPerl here for this.
In the next step with the module.
Btw. I altered the script from
ftp://ftp.fvwm.org/pub/fvwm/devel/sources/tests/perl/xmessage.fpl
and no, I don't reinvented the wheel as you see. Ok, it's not the
best way ... give me some time to put this in a correct module,
ok? But for now it is a usable approach. Or not?

Fixed script is attached.

@Dan:
I found a wrong typo in the manpage. Please change
Module FvwmPerl -l fvwm-menu-desktop-gui.fpl
to
Module FvwmPerl -l fvwm-menu-desktop-config.fpl

Thanks.
Thomas




# This script generates a FvwmForm similar to the FvwmForm-Desktop by
# Dan Espen but insert the found xdg menus dynamically into the Form
# before processed.
# Author: Thomas Funk t.f...@web.de
# Version: 1.1

package MenuConfig;
use File::Basename;
use strict;
use warnings;

#open(MSG ,[path]/log.txt) || die Error $!;

my $all = `fvwm-menu-desktop --get-menus all`;
my $selected = `fvwm-menu-desktop --get-menus selected`;

my @all_filelist = split(/ /,$all);
my @selected_filelist = split(/ /,$selected);

my %all_menus = ();
my %selected__menus = ();
my $max_length = 0;
foreach my $path (@selected_filelist) {
my ($filename, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);
push (@{$selected__menus{$directories}}, $filename);
}

my $i = 1;
foreach my $path (@all_filelist) {
my $name = MEN . $i;
# qr matched against the end of the $filename. 
# The matching portion is removed and becomes the $suffix.
my ($filename, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);
push (@{$all_menus{$directories}{$i}}, ($filename, $name, off));
next if !defined $selected__menus{$directories};
foreach my $hit (@{$selected__menus{$directories}}) {
 if ($filename eq $hit) {
 pop (@{$all_menus{$directories}{$i}});
 push (@{$all_menus{$directories}{$i}}, on);
 }
}
$max_length = length($filename) if ($max_length  length($filename));
$i++;
}

my $fvwmform_commands = 
DestroyModuleConfig  FvwmForm-Desktop: *
*FvwmForm-Desktop: WarpPointer
*FvwmForm-Desktop: Title\fvwm-menu-desktop options\
*FvwmForm-Desktop: Line center
*FvwmForm-Desktop: Text \-- Multiple Menu 
--\
*FvwmForm-Desktop: Line 
;

foreach my $key (sort( keys %all_menus)) {
$fvwmform_commands .= 
*FvwmForm-Desktop: Line left
*FvwmForm-Desktop: Text \Menus in $key\
*FvwmForm-Desktop: Line left
*FvwmForm-Desktop: Selection meth multiple
;
my $m_count = 0;
foreach my $count (sort(keys %{$all_menus{$key}})) {
my @menu = @{$all_menus{$key}{$count}};
my $newstring = $menu[0] . ' ' x eval($max_length-length($menu[0]));
$fvwmform_commands .= *FvwmForm-Desktop: Choice  $menu[1] $menu[1] 
$menu[2] \$newstring\
;
$m_count++;
if ($m_count == 3) {
$fvwmform_commands .= 
*FvwmForm-Desktop: Line left
*FvwmForm-Desktop: Selection meth multiple
;
$m_count = 0;
}
}
$fvwmform_commands .= 
*FvwmForm-Desktop: Line left
*FvwmForm-Desktop: Text \ \
;
}

$fvwmform_commands .= 
*FvwmForm-Desktop: Line center
*FvwmForm-Desktop: Text \-- General Options 
--\
*FvwmForm-Desktop: Line
*FvwmForm-Desktop: Line Left
*FvwmForm-Desktop: Text \Use Icons in Menus?   \
*FvwmForm-Desktop: SelectionSelItype single
*FvwmForm-Desktop: Choice   IconsOn  IconsOnon  \Yes\
*FvwmForm-Desktop: Choice   IconsOff IconsOff   off \No\

*FvwmForm-Desktop: Line left
*FvwmForm-Desktop: Text \Icon size:\
*FvwmForm-Desktop: InputSize 2

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Thomas Adam tho...@fvwm.org wrote:
 On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote:
 I'm guessing the other fvwm developers are okay with going to asciidoc?
 No.  I have an attempt at this, but it's not finished.  We either use
 groff or nothing, and I don't mean groff backported from some
 conversion tool.  If you don't know groff, start learning.
Ok :S ... not as punishment - only as exercise

Btw I used asciidoc to show my thoughts and examples only not to
check in.

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/16 Thomas Adam tho...@fvwm.org wrote:
 Isn't this in the XDG spec as to which menus appear where, in
 categories?  I'm sure it is.
That's right. The process (the python-xdg lib) which generates the menus
follow this. But fvwm-menu-desktop only calls the methods for each menu
found in the system. The structure which sub menus appear per menu is hard
coded IN the xml menus not in the fvwm-menu-desktop code.

 One possibility could be to create the menus and then search for double
 entries, eliminate them and if a menu is empty delete it. But the actual

 No.  That's just admitting to not wanting to fix the problem.  :)
That hush me ^^

 In the next days I will present a fvwm-menu-desktop config tool based on
 FvwmPerl which shows all founded menus on the system and let the user
 decide which menu/menus she/he wants to create and how.

 That might be useful longer-term, but I think I'd rather see the
 basics of this menu generation working first of all.
The basics work - you can generate all menus, some of them, single ones.
Plus, the config tool is finished already. Needs only some tests ... On my
Debian all works. On Fedora also ...

Thomas

Re: Reworked fvwm-menu-desktop

[Thomas Funk]

-Ursprüngliche Nachricht-
Von: Thomas Adam tho...@fvwm.org
Gesendet: 01.11.2011 13:12:56

Dan didn't construct that structure, that's how it was originally based on
parsing the XML files for the XDG menu definitions, and it's always been the
structured formed from the XDG data which I've had an issue with, since it's
very inefficient.

And it's this, including my reply to you previously in this thread, which I
was hoping you'd be addressing. Yes, the XDG spec talks about merging items
together, etc., and that's fine, but making that a direct facet of how the
data is structured and stored is not the bes thing to do, IMO.

Ok, I will try to find a better structure or way for the data ... but i cannot 
promise anything ...

Cheers,
Thomas

--
Life is like a box of chocolates - never know what you're gonna get.


___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: Reworked fvwm-menu-desktop

[Thomas Funk]

-Ursprüngliche Nachricht-
Von: Thomas Adam tho...@fvwm.org
Gesendet: 20.10.2011 15:00:58
An: Thomas Funk t.f...@web.de
Betreff: Re: Reworked fvwm-menu-desktop

Some very quick observations...
[...]

Can you describe the internal data overall, and now it's derived, and then
we can look at how best to process it. That way, we can reduce a lot of the
clutter, and define a more cleaner interface for all of this.

Hi Thomas,
sorry for the delay, but I was seriously ill the last days. But now I've done 
the description of merge_fvwm2_menus.
Hope it's ok:


sub merge_fvwm2_menus {
    my $weight = 0;
    my $reference_menu;
    # check first if xdg_menu_prefix is set
    if (defined $xdg_menu_prefix) {
    $reference_menu = $xdg_menu_prefix;
    } else {
    # check if applications.menu exist
    # question: correct to disable autovivification?
    if (ref $fvwm2_menus{''} eq 'HASH') {
    $reference_menu = '';
    } else {
    # get the biggest menu as reference
    foreach my $prefix (keys %fvwm2_menus) {
    my $size = scalar keys %{$fvwm2_menus{$prefix}};
    if ($size  $weight) {
    $reference_menu = $prefix;
    $weight = $size;
    }
    }
    }
    }
    ## compare the other menus with reference and delete same entries
    # create an fvwm menu hash
    %{$fvwm2_menus{'fvwm-'}} = %{$fvwm2_menus{$reference_menu}};
    # get the first hash key ('gnome-', 'kde-', 'fvwm-')
    foreach my $compare_menu (keys %fvwm2_menus) {
    # don't check the reference or the fvwm menu
    next if ($compare_menu eq $reference_menu || $compare_menu eq 'fvwm-');
    # get the menu names from the reference menu (check the known menus for 
same entries)
    foreach my $refkey (keys %{$fvwm2_menus{$reference_menu}}) {
    # get the menu names from the menu should compared
    foreach my $compkey (keys %{$fvwm2_menus{$compare_menu}}) {
    # compare array A (@{$fvwm2_menus{$compare_menu}{$compkey}}) to 
Array B (@{$fvwm2_menus{$reference_menu}{$refkey}})
    # and removing B elements from A. Exception: DestroyMenu and 
AddToMenu entires
    my @rest = grep { my $x = $_; not grep { $x =~ /\Q$_/i and $x 
!~ /DestroyMenu|AddToMenu/} @{$fvwm2_menus{$reference_menu}{$refkey}} } 
@{$fvwm2_menus{$compare_menu}{$compkey}};
    # clear compared array
    undef @{ $fvwm2_menus{$compare_menu}{$compkey} };
    # push cleared array into compare array
    push @{ $fvwm2_menus{$compare_menu}{$compkey} }, @rest;
    # if only DestroyMenu or AddToMenu entries exist, delete this 
menu name hash
    if (scalar @{ $fvwm2_menus{$compare_menu}{$compkey} } == 2) {
    delete $fvwm2_menus{$compare_menu}{$compkey};
    }
    }
    }
    ## check if double entries in the compare menu exist and delete them
    # this happens on OpenSuSE 11.4 where in System AND Settings the same 
app entries exist
    foreach my $refkey (keys %{$fvwm2_menus{$compare_menu}}) {
    foreach my $compkey (keys %{$fvwm2_menus{$compare_menu}}) {
    next if ($compkey eq $refkey);
    my @rest = grep { my $x = $_; not grep { $x =~ /\Q$_/i and $x 
!~ /DestroyMenu|AddToMenu/} @{$fvwm2_menus{$compare_menu}{$refkey}} } 
@{$fvwm2_menus{$compare_menu}{$compkey}};
    undef @{ $fvwm2_menus{$compare_menu}{$compkey} };
    push @{ $fvwm2_menus{$compare_menu}{$compkey} }, @rest;
    }
    # if only DestroyMenu or AddToMenu entries exist in a reference 
menu, delete the menu name hash
    if (scalar @{ $fvwm2_menus{$compare_menu}{$refkey} } == 2) {
    delete $fvwm2_menus{$compare_menu}{$refkey};
    }
    }
    ## merge all '+' entries in existing ref menus
    foreach my $key (keys %{$fvwm2_menus{$compare_menu}}) {
    # don't check the fvwm root menu. This we will do later
    next if ($key eq 'FvwmMenu');
    # if menu name from compare menu exists in reference menu try 
merging
    # question: is defined correct to disable autovivification?
    if (defined $fvwm2_menus{$reference_menu}{$key}) {
    # get all + entries except with Popup|DestroyMenu|AddToMenu
    my @entries = (grep (/\+/, 
@{$fvwm2_menus{$compare_menu}{$key}}) and grep (!/Popup|DestroyMenu|AddToMenu/, 
@{$fvwm2_menus{$compare_menu}{$key}}));
    # if entries array has values, push lines into reference menu
    if (@entries) {
    push @{ $fvwm2_menus{$reference_menu}{$key} }, @entries;
    # get the rest like Popup|DestroyMenu|AddToMenu entries to 
create the
    # compare menu without the + entries moved to the reference
    my @rest = grep

Re: Reworked fvwm-menu-desktop

[Thomas Funk]

On Thu, Oct 20, 2011 at 12:12:43PM +0200, Thomas Adam wrote:
Thanks, but I'd like to see a unified diff, not an entire file.

Uuups, sorry :S

Attached.

--
Life is like a box of chocolates - never know what you're gonna get.

___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192


diff.txt
Description: Binary data

Re: Reworked fvwm-menu-desktop

[Thomas Funk]

-Ursprüngliche Nachricht-
Von: Thomas Adam tho...@fvwm.org
Gesendet: 20.10.2011 15:00:58
An: Thomas Funk t.f...@web.de
Betreff: Re: Reworked fvwm-menu-desktop

Some very quick observations...

+my $xdg_data_home = $ENV{XDG_DATA_HOME} || $ENV{HOME}/.local/share;
+my $xdg_menu_prefix = $ENV{XDG_MENU_PREFIX} || '';
+my %xdg_menus;
 my @PATH_DIRS = split(':',$ENV{PATH}); # for checking if applications exist

Why?
because it's follows the xdg spec.
Ok, $xdg_data_home not used. so can be deleted.
%xdg_menus is the hash to hold the founded menus:
%xdg_menus = { 'xdg_prefix' = 'file' }

 my $version = '2.6.4';
 my $menu_prefix='FvwmMenu';
 my $DefaultAppDirs;
@@ -116,19 +144,22 @@
 my $charset = 'iso-8859-1';
 my $root_cmd;
 my $kde_cmd;
+my $menu_content = 'applications';
+my $global = 0;

What's global here?
I use it for system wide menus. If not set (0) look first in $xdg_config_home
and if empty look in $xdg_config_dirs. Ok, perhaps bad coice of command name ...

my $die_on_error = 0;
 my $verbose = 0;
+my $desktop;

 my @language_keys;

 #my @accessed_files;
 my $TERM_CMD = xterm -e;

-

Why?
because it's a command line variable? I thought I need it. It's like the same
as with $kde_cmd. Or not?

[...]

+if (defined $desktop) {
+ $xdg_menu_prefix = $desktop-;
+}
+
 # kde-config helps us find things.
 # sometimes it has funny names.
 # we can get by without it.
@@ -225,7 +262,25 @@
 $DefaultAppDirs = get_app_dirs();
 $DefaultDirectoryDirs = get_desktop_dirs();

-$root_menu = get_root_menu();

Would be nice to use File::BaseDir to be honest for all of this.
Must RTFM first ...

+# get menus
+unless ($global) {
+ # first check user home
+ foreach my $dir (split(/:/, $xdg_config_home)) {
+ my $user_file_list = get_file_list($dir/menus, 0);

What's 0 here supposed to signify?
If $global = 0 (default) then the user home have to check first (xdg spec)
Is if (!$global) better?

+ print \n;
+ foreach my $prefix (sort (keys %xdg_menus)) {
+ warn \tDEBUG: ${prefix}menu is \'$xdg_menus{$prefix}\'.;

Read up on the qq operator here.
Ok, will do

+foreach my $prefix (sort (keys %xdg_menus)) {

You sort this a lot -- why?
I sort it because an empty key ('' = applications.menu) should start first.
But I see, in this case it is useless.
Can you not sort %xdg_menus once, or better yet Tie it?
I red often that hash keys cannot sorted. They will be written
randomly into the hash structure. So, therefore I sort them ever i need it ...

- if ($file !~ /^\// and defined $basedir)
- {
- $file = $basedir/$file;
- }
-
 unless (defined $basedir)
 {
 $basedir = $file;
 $basedir =~ s/\/[^\/]*$//;
+ } else {
+ if ($file !~ /^\// and defined $basedir)
+ {
+ $file = $basedir/$file;
+ } else {
+ $basedir = $file;
+ $basedir =~ s/\/[^\/]*$//;

Do we guarantee -d $basedir at all with all this mangling? See File::Copy
for instance.
The problem here was that not all included menus found.
This happens on my Debian system:
$HOME/.config/menus/gnome-applications.menu includes the gnome-applications.menu
which is located in /etc/xdg/menus. This menu includes the Debian menu which was
also located in /etc/xdg/menus/. The reading of this menu failed in the old
implementation because the script wants to read it under $HOME/.config/menus/

+sub get_file_list
+{
+ my ($path, $subdirs) = @_;
+ $subdirs = defined($subdirs)?$subdirs:0;

But $subdirs is always defined here -- you're passing it in. Note that the
idiom you're referring to is:

$subdirs ||= 0;

Hmm .. ok. I confess that I've copied the function from my work on
fvwm-themes-config :S and this code is from a site about file handling.
I rewrite it for my needs and it fits here to get the files I needed.
Must rethink about the implementation (blush) ...

+ my %files = ();
+ push (my @all_directories, $path);

Why?

+ foreach my $dir (@all_directories) {
+ opendir (my $IN, $dir) || return {};
+ my @all = readdir($IN);
+ closedir $IN;
+
+ foreach my $file (@all) {
+ next if ($file eq '..' || $file eq '.');

You can avoid this by not slurping readdir into an array.

my @all = grep { !/^\.+/ and -d } readdir(...);

And note that @all needs a better name.

+ if (-d $dir/$file) {
+ if ($subdirs == 1) {
+ push (@all_directories, $dir/$file);
+ $files{$dir/$file} = $file;

Nasty to use a key name like that.

-# Fixme, remove unsupported options.
+sub get_prefixes_and_menus {
+ my $file_list = shift;
+ my $verbosecheck = 0;
+ foreach my $file (sort (keys %{$file_list})) {

Why sort?

+ next if (-d $file);

Unlikely.

+ if ($file_list-{$file} =~ m/(.*)$menu_content.menu(.*)/) {

This is a little ugly, given the interolation each time. Substr() the
thing instead.

+ my $front_prefix = $1;
+ my $back_prefix = $2;

You should always check these, especially given the greedy patten match.

+sub create_fvwm2_menu_hash {
+ my $menu = shift;
+ my %new_menu = ();
+ my @reference_menu = split(\n, $menu);
+ # first create menu hashes
+ foreach my $line (@reference_menu) {
+ if ($line =~ m/^DestroyMenu