From: Carsten H. (T. R. <ra...@ra...> - 2001-08-12 12:44:14
|
On Sat, 11 Aug 2001 21:26:17 -0700 Christian Hammond <ch...@po...> babbled profusely: > On Sun, Aug 12, 2001 at 01:20:50PM +1000, Carsten Haitzler wrote: > > please help come up with a fix that woudl solve this problem and agree to > > compromise. conditions: > > it must not break the existing api > > it can add to the api > > it must work in 100% of cases (no point of doign a fix for 99% of cases i we > > still miss 1%) > > Just throwing in my two cents... > > Now, I haven't studied the Imlib2 code in great detail, so forgive me > if I'm wrong about how some of the internals work. I have looked at it > a bit in the past, and I tried to re-educate myself a bit before > sending this e-mail :) > > Why not add a new function to the loaders which, if specified in the > loader, will return either a 1 or 0 specifying if it supports the > special ':' character in the filenames. If the loader does not include > this function, it can default to 0, as most images wouldn't do > anything special if a ':' is in the filename anyway. > > If the loader specifies that it does do something special with the > ':', then Imlib2 can go ahead and do what it is currently doing. > However, if the loader returns 0, or the function doesn't exist, then > Imlib2 can skip all the __imlib_FileRealFile() checking, and anything > else that may be relevant. > > This would satisfy #1 and #2 on your list, as everybody could keep on > using Imlib2 as they previously did without changing any of their code. > Existing loaders would not be broken, but loaders that take advantage > of the ':' would need to provide that function. > > As for #3, it should work in all cases except for when the file > containing the ':' also uses a ':' as part of its filename. That > should be able to be solved fairly easily, I'd imagine, by just > looping through the string from right to left, stopping at each ':', > and seeing if the string before it exists as a file. > > You could even take that a step further. If the file exists, try to > open it with that key. If it fails, find the previous ':', check if > the file exists, and open that. Lather, rinse, repeat. > > I use a similar method in a library I'm working on, which makes use of > loadable modules. It seems to work pretty well. > > Anyhow, feel free to use it, adapt it, or ignore it. I just hope you > guys can get back to coding instead of arguing :) hmmm let me think... actually this doesnt need to be done if the file checks go inside the loaders.. but its not a small change... this change is a reaosnable lump of code (a few hundred lines to do right 200 maybe)... but this means all the fiel checks pre loader call need to be done inside the loader. i put them outside the loader for speed reasons originally (so they are done once for basic file checks...) instead of each time a loader is tried... kind of slightly more optimal... but your idea has some merit... let me think.. mayeb it coudl be combined with some stuff to work better... > -- > Christian Hammond <> The GNUpdate Project > ch...@po... <> http://www.gnupdate.org/ > > _______________________________________________ > Enlightenment-devel mailing list > Enl...@li... > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +61 (0)408 363 984 Work Phone: +61 (02) 9386 9362 |