[Crystal-audio-users] FVWM-Crystal rearrangements

[Dominique M. <dom...@ci...>]

Maciej and me are currently working to include Crystal Audio features into
FVWM-Crytal.

=46rom now, we will use this list to discuss the different issues, so at every
one can participate.

Le Wed, 11 Apr 2007 00:31:55 +0200,
Maciej Delmanowski <ha...@li...> a =C3=A9crit :

> Thomas Adam told me that he was concerned about some bugs in your code, h=
as he
> contacted with you about that issue?
>

I made a thread on the gentoo forum
http://forums.gentoo.org/viewtopic-t-540527-highlight-.html

Thomas made some remarks, I corrected accordingly when it was specific thin=
gs,
but a remark as "Note that whilst it is a nice idea of yours to autogenerate
this, what you're doing leaves yourself *wide* open to massive exploits. I
don't see *any* error checking in any of this." don't help me much.

I am not a shell expert, and when asking him to at least provide me a point=
er
to some documentation that can help me, he never answered.

About the error checking, I don't use it because I made the assumption at
desktop files in a system are valid desktop files. If it is more to concern
about, please someone tell me.

It is 2 scripts in this thread, the second one will be not needed at all in=
 the
future FVWM-Crystal release because the menu re-organization will already be
done.

The script that generate the menu entry from desktop file proceed by steps:

1) It search for all the desktop files in a few given system directories, or
for one specific desktop file. Look at the end of the script, it is the
$searchdesktop $1 function. In this function, it sort out all the non
application type desktop files and a few other that we don't want in your m=
enu.
To be valid for further traitment, a desktop file must contain the key
"Type=3DApplication", and not contain any of the key "OnlyShowIn",
"NotShowIn", "NoDisplay" or "Hidden".

2) searchexecname: search for the Exec=3D key and extract the exec string. =
It is
some sed filtering here, but again, if the key contain non valid string, I
think at it is not the job of this script to take it in account but the job=
 of
the one providing the problematic desktop file.=20

The consequence in this script is at it will generate a menu entry that will
not work, because the first part of it name will not correspond to any
executable, and the command inside the entry will not correspond either to =
any
executable. And with hundred of desktop files in my system, I don't find any
such problematic case, even after removing fvwm-crystal /application tree in
order to force the script to generate all the menu entry.

3) searchiconame: search for "Icon=3D" key and extract the icon name.

4) searchexist: set EXIST=3Dtrue/false; true =3D the corresponding FVWM-Cry=
stal
menu entry already exist; false =3D the corresponding FVWM-Crystal menu ent=
ry
don't exist.

In both cases, "createicon" is run. createicon check if the icon already
exist in FVWM-Crystal /icons, do nothing if true, look for an icon as found=
 by
searchiconame, or for an alternative icon, and generate the fvwm-crystal ic=
ons
with the first suitable icon found. createicon come from the debian
so-called "menu" package.

5) if EXIST=3Dtrue, nothing more is done and the script skip to the next de=
sktop
file as defined by 1) searchdesktop.

if EXIST=3Dfalse, the following steps are done:

6) searchkeystrings: search for the following keys in the desktop file and
extract the strings:
Categories=3D but only inside a "Desktop Entry" structure.
Name=3D but only inside a "Desktop Entry" structure.
Exec=3D but only inside a "Desktop Entry" structure.
Terminal=3D

7) gen_category: generate main and sub categories and filter out some non
wanted categories as X-Red-Hat or X-Suse

8) check_category: make some additional check and generate FVWM-Crystal
category.

9) generate FVWM-Crystal menu entry with gen_consoleentry if Terminal=3Dtru=
e,
with gen_entry otherwise.


> > I can also skip the wallpaper. I
> > don't remember where I get it, maybe on usenet, but I am sure at it is =
not
> > a free picture, so it will break the GPL.=20
>=20
> And with the wallpaper, maybe you can try contacting the author and
> ask him for a permission to redistribute his work in FVWM-Crystal? We can=
 add
> his decision in the doc/ directory as a separate file. But, it may still =
be
> a violation of the GPL... Hard to say.
> >=20

It is from Jose Correa. I don't find its webpage if he has one, but I find =
this
link: http://excideuil.hautperigord.com/2007/04/02/exposition-jose-correa/ =
and
I just send them an email where I ask them about how I can take contact with
him.

> > I can also done a patch with just the supplementary icons for the
> > applications menu. Most original pictures are free. And I believe at, e=
ven
> > when I cannot be sure at the original picture was free, the resulting i=
con
> > file --that is resulting from scaling down the original pic and at least
> > removing or changing some part of the pic with GIMP-- must be free.=20
>=20
> The thing is, I've done the resizing with the Firefox icon, and Debian te=
am
> still refused to include the new release in the distribution... But that's
> maybe because of the different licensing of the Mozilla Firefox logo. Any=
way,
> thanks for the icons! I'm planning to use more app icons from Tango Proje=
ct,
> especially those from http://tango.freedesktop.org/Tango_Fridays
>=20
They have nice icons.

> > Another issue with those icons is at I don't like some of them. As exam=
ple,
> > alsaplayer icon is looking good with a 1024x680 screen resolution, but =
very
> > bad at 1680x1200 screen resolution.
>=20
> So it's time for an icon hunt. :)
>=20

I have some test with stalonetray and get better results with it as with
trayer. But it is huge syntax differences between the two programs.

> > It is a good idea. I think at the simpler will be the best. A major
> > difference between stalonetray and trayer is at we must use a fvwmbutton
> > with stalonetray in order to get percentage transparency support and a
> > unified style. That implies as the stalonetray notification area cannot
> > shrink or grow with a fvwmbutton.
>=20
> I've had the same problem with trayer when I was adding it to the project,
> weither to swallow it to FvwmButtons, or use it as a free window with
> specified parameters. Swallow would be easier from FVWM stand point, beca=
use
> when you need to setup is the FvwmButtons... But it didn't work as expect=
ed so
> I just left trayer "as is". And now I would like to have stalonetray work=
 in
> the same manner... Maybe it would be easier to just add the tinting suppo=
rt in
> the application? What does the author say about that, can he use imlib, or
> something similar?
>=20
Stalonetray is already able to grow, and the shrink back function will be
included in the next release. He also said at percentage transparency suppo=
rt
is possible to implement if I want to, but at it is a assle to implement and
will take some time.

My modified recipes use a fvwm-buttons, so they will not be able to grow and
shrink, but I implemented a single variable in /component/function/Trayer,
variable that is used by all the recipes to modify the size of the
Trayer fvwm-button. Maybe at it will be better to have it as a preference
setting in the menu.

> > I think at you want to rename generate-fvwm-crystal-menu too. Something=
 as
> > fvwm-crystal-generate-desktop-menu maybe.
>=20
> Good idea, thanks. :) I'll look into it soon.
>=20
> > I am thinking to incorporate it in the menu, but a few small modificati=
ons
> > will be needed in order to preserve the possibility to search for a giv=
en
> > entry or for all the desktop files. But I am not sure if it is a good i=
dea
> > to have it in the menu because the path of the desktop file is distribu=
tion
> > dependant. That implies at an user have to edit the script before to ru=
n it:
>=20
> We can setup some variables in the 'fvwm-crystal' script, or in fvwm/conf=
ig...
> Anyway the best solution would be to use the makefile to change the patch=
es in
> the script, and create separate makefile entries for each distribution, a=
nd
> then check which one is currently being used and decide at this time.
>=20
> > FC_MENUBASEROOT and FC_ICONBASEROOT can easily be fixed with the Makefi=
le
> > and sed, but DesktopDir and SYSTEM_ICONDIRS are distribution dependant.=
 A
> > workaround will be to search the whole /usr and /opt trees with
> > DesktopDir=3D"/usr /opt" and SYSTEM_ICONDIRS=3D"/usr /opt", it will work
> > but will be very time consuming.
>=20
> DesktopDir and SYSTEM_ICONDIRS can also be modified by the Makefile, just=
 need
> to add some code to figure out which distribution we are dealing with.
>=20
Peoples installing from sources are one issue, and it must be easy to fix t=
he
FVWM-Crystal directories in the Makefile with the prefix option.

Distribution dependant files are another issue, and it is so many distribut=
ions
around at I don't think at it will be possible to insure at it will work in=
 any
case. It even become more complicated when some users can run fvwn and
fvwm-crystal on old distributions that will not necessarily use the same
directory structure for the desktop files as the current version.

I think at it will be necessary to talk about it in the INSTALL file, and at
peoples installing from the sources will have to fix it before running the
script.=20

We can also made some modifications in the Makefile. My script use the gent=
oo
file structure. I can provide Suse 10.1 file structure with no guaranty at =
it
will work with other Suse versions. Maybe at we can ask the major distribut=
ions
about it.

I also think at it will be the job of the respective developers to fix this
script for their distributions.

Ciao,
Dominique