On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <[email protected]> wrote: > Hello! > > PCMan has written on Monday, 18 March, at 11:50: >>I'm afraid that the multiple-backend design is overly-engineered. >>Though it looks much more flexible, there is no real-world use cases >>since we don't mix multiple image libraries in one GUI project. For >>example, you won't use both of QImage and GdkPixbuf in a Qt project, >>and vice versa. I'm not against making things flexible, but if there >>are no valid real-world use case, I prefer KISS. > > Well, it have rights to be once-set, of course, but any good design > should have errors checking code. If you look into my letter (arghh, that > top-posting again!) then you can see I've written that I don't like the > possibility to accidentally overwrite data which will be left unnoticed. > Therefore we have to have error check in fm_thumbnail_loader_set_backend > function and return some error code instead of void return. Am I wrong on > that?
Then we can make it return gboolean and check if the backend functions have already been set. If it's already set, we prohibit overwriting the old function table and returns FALSE. Is this OK for you? >>> And I also think fm_thumbnail_result_* isn't good name for the API. >>> Result is an item literally and fm_thumbnail_result_cancel() sounds very >>> odd. How can we cancel result? We can cancel task, request, whatever is a >>> process, only process is cancellable, not item which we got. Therefore I >>> think there should be better name for this API family. What about, for >>> example, fm_thumbnail_loader_*? That should look better I believe, and >>> also it unifies all names (part of them are fm_thumbnail_loader_* now but >>> part are fm_thumbnail_result_*). The proposed fm_thumbnail_loader() name unfortunately is already taken and used in other places. To avoid name clashes, I named it *_result_*. Please see fm-thumbnail-loader.[hc] files. It's true that the naming is bad but I'm not able to come up with a better one at the moment. In xmms2 client library, they call pending result of async calls "result". That's where I got the idea. In Qt, the naming is more weird. They call it "future" since the result will be returned in the "future". So there is a C++ class named QFuture in it, which I consider very odd. Any better suggestion about the naming/wording here? >>> What do you think about it? > > I waited for your thoughts and still got no answer. I believe you > just missed this block in my letter. Comment it, please! > > With the best wishes. > Andriy. > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Pcmanfm-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Pcmanfm-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
