Maciej and me are currently working to include Crystal Audio features into FVWM-Crytal.
From 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 <[EMAIL PROTECTED]> a écrit : > Thomas Adam told me that he was concerned about some bugs in your code, has 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 things, 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 pointer 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 menu. To be valid for further traitment, a desktop file must contain the key "Type=Application", and not contain any of the key "OnlyShowIn", "NotShowIn", "NoDisplay" or "Hidden". 2) searchexecname: search for the Exec= 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. 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=" key and extract the icon name. 4) searchexist: set EXIST=true/false; true = the corresponding FVWM-Crystal menu entry already exist; false = the corresponding FVWM-Crystal menu entry 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 icons with the first suitable icon found. createicon come from the debian so-called "menu" package. 5) if EXIST=true, nothing more is done and the script skip to the next desktop file as defined by 1) searchdesktop. if EXIST=false, the following steps are done: 6) searchkeystrings: search for the following keys in the desktop file and extract the strings: Categories= but only inside a "Desktop Entry" structure. Name= but only inside a "Desktop Entry" structure. Exec= but only inside a "Desktop Entry" structure. Terminal= 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=true, 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. > > 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. > > 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, even > > when I cannot be sure at the original picture was free, the resulting icon > > 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. > > The thing is, I've done the resizing with the Firefox icon, and Debian team > still refused to include the new release in the distribution... But that's > maybe because of the different licensing of the Mozilla Firefox logo. Anyway, > thanks for the icons! I'm planning to use more app icons from Tango Project, > especially those from http://tango.freedesktop.org/Tango_Fridays > They have nice icons. > > Another issue with those icons is at I don't like some of them. As example, > > alsaplayer icon is looking good with a 1024x680 screen resolution, but very > > bad at 1680x1200 screen resolution. > > So it's time for an icon hunt. :) > 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. > > 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, because > when you need to setup is the FvwmButtons... But it didn't work as expected 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 support in > the application? What does the author say about that, can he use imlib, or > something similar? > Stalonetray is already able to grow, and the shrink back function will be included in the next release. He also said at percentage transparency support 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. > > Good idea, thanks. :) I'll look into it soon. > > > I am thinking to incorporate it in the menu, but a few small modifications > > will be needed in order to preserve the possibility to search for a given > > entry or for all the desktop files. But I am not sure if it is a good idea > > to have it in the menu because the path of the desktop file is distribution > > dependant. That implies at an user have to edit the script before to run it: > > We can setup some variables in the 'fvwm-crystal' script, or in fvwm/config... > Anyway the best solution would be to use the makefile to change the patches in > the script, and create separate makefile entries for each distribution, and > then check which one is currently being used and decide at this time. > > > FC_MENUBASEROOT and FC_ICONBASEROOT can easily be fixed with the Makefile > > and sed, but DesktopDir and SYSTEM_ICONDIRS are distribution dependant. A > > workaround will be to search the whole /usr and /opt trees with > > DesktopDir="/usr /opt" and SYSTEM_ICONDIRS="/usr /opt", it will work > > but will be very time consuming. > > 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. > Peoples installing from sources are one issue, and it must be easy to fix the FVWM-Crystal directories in the Makefile with the prefix option. Distribution dependant files are another issue, and it is so many distributions 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. We can also made some modifications in the Makefile. My script use the gentoo 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 distributions about it. I also think at it will be the job of the respective developers to fix this script for their distributions. Ciao, Dominique _______________________________________________ fvwm-crystal-users mailing list fvwm-crystal-users@gna.org https://mail.gna.org/listinfo/fvwm-crystal-users
