There are a few TODO items for E17 - "* fm2 .desktop parser needs to handle i18n * use .desktop files and move eap editor to edit them etc. etc. instead to fix * if we want to do icons on the desktop - and as part of efm, i am thinking that we have little choice but to implement a .desktop file loader. this is not to hard - it's the xml jungle of the system menus that is sucky. the real problems are where to find the icons for the .desktop files."
I already have all the code for parsing .desktop files and finding the icons according to the freedesktop.org (fdo) specs. Also, to support xsession files, essiene wants me to make the code available to entrance, since those are .desktop files. So the question becomes, where to put the code. I'm ready to cut and paste, just gotta know where. (I also have xml jungle menu code.) According to rasters plans, we are replacing .eap files with .desktop files. Argue with him about the plans, I'm just implementing them since I have the code all ready to go. My initial plans are to implement .desktop file loading alongside .eap loading, so that .order files for instance could contain a mixture of both. This gives us a grace period where things wont break while we change over. The .eap code is in e_apps.c, and there is some really basic .desktop parsing code in e_fm.c. That's not the best place if entrance wants to re use the code. Evas or ecore are the candidates I am considering. Evas because we are essentially loading an image and some metadata. Ecore, because evas needs some extra API to allow the requesting of specific sizes. There may be a better place. Let me go over the relevant details. The information in a .desktop file is not complete, it requires the rest of the freedesktop.org system to be in place to be able to gather all the information required to actually load the icon. Any distro that is using .desktop files has that system in place, it's just up to the code to follow the spec and ferret out all that info. Typically a .desktop file only supplies the base name of the icon, you have to go through the fdo procedure to find an actual file with image data in it. Those files will be PNGs, SVGs, or XPMs. PNGs we can handle, XPMs we can add support for, SVGs are currently considered to hard, and are being left until later. What particular mix of PNG, SVG, and XPMs might be found is usually upto the distro makers to decide. The user can install more icon themes at any stage. So we will be getting lots of complaints until we support all three formats. There are a few sources of paths to search for both icons and .desktop files. These include things like default paths, optional paths, environment variables, programs to run that return paths, KDE and GNOME can supply paths if they are installed, etc. KDE or GNOME are likely to be installed, and a lot of distros setup their fdo systems to suit those wms, so it is worthwhile using them as sources of search paths. E17 has it's own method of allowing the user to define search paths, this can also be used. The end result is prioritised lists of places to look for .desktop and icon files. According to the fdo specs, the user is allowed to select an icon size and theme. The spec contains methods of looking through the search paths to determine what icon themes and sizes are available. There is a fallback size and theme that every system must supply, but it doesn't have to be the default. B-) This is what makes evas a bad choice, it doesn't currently have an API for "give me this image in this size", let alone taking into account the theme element. This is also one of the reasons that SVG is too hard, since it's a vector format, a size will need to be specified for evas to load it. Another issue is that although the fdo spec includes window class info in the .desktop file for the purposes of startup notification, I haven't seen many .desktop file that actually include that information. In the case of eaps, the user either typed it in manually, or it came from a currently running application, so I don't think that is a major concern. Finally, my .desktop implementation requires a hash and a list implementation, and the xml jungle code requires a tree. No external xml parser is needed, as I wrote a simple one that is just enough to parse fdo menu files. The .desktop files are not xml, they are more like Windows .ini files. Ecore supplies all the needed functionality, which is the reason I think it's a good place for the .desktop code. So, where do I put this code?
signature.asc
Description: PGP signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
