David Seikel wrote: It seems there are two things going on here, 1) parsing and 2)loading with the parsed information. I think striving to keep the two seperate will be good overall (i'm saying this without having a clear view of the situation that you have). Next below... > <snip> > 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.) > I feel the parsing belongs in ecore. Since ecore is like central plumbing, it makes sense to put this there. I expect to call, ecore_dotdesktop_parse(a_pointer_to_struct_dotdesktop, "/path/to/foobar.desktop") and it populates that struct with, name, full path to icon (which has been located via freedesktop.org kung-fu), full path to executable or executable name to be found in $PATH, etc... this part of the work, I feel should belong to ecore_...). Just ignore my description above, since you obviously have something already, just an explanation of tot process. > 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 second part in this process is .desktop file loading, which I believe refers to the ability to use a specified .desktop file to create an visible icon, which when we click on it, it executes the executable refered to in the .desktop file. This part of it, i feel is distinct enuff and belongs to Evas. It falls in line with *loading and image and some metadata*. Evas in this case would use the ecore routines to grab the meta data (would this create a cyclic dependency? if it does, then every thing can be done in evas, but as _seperate_ subsystems, though the parsing part... really *smells* like ecore stuff). > 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. > this work should all be done by the parsing parts. > 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. > if the ecore_parser part is quizzed for the image size, it can return the proper image path in the "struct" and then the evas loading part can commence to load this. > 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. > dunno much about this guys... no comment :) > 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. > the heavy lifting should surely be done by ecore, like you said, all you need is there already. you could add a simple tree there for this purpose i guess. > So, where do I put this code? > > IMOHO, i think the parsing part belongs to ecore, and the loading part to evas (this will call the parsing part from ecore, provided there's no circular dependency being created).
okie dokie... how's that for being helpfull :) Oh... and good work. /me settles down to lazily wait for grossly underpaid onefang to solve all headaches :) Cheers, Essien > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
