OK, then rename them all with fm_thumbnail_loader_*. Would you please do the changes we discussed about for me while you're doing the merging? I don't have time for coding today and I'm using Windows now. :-( Thank you.
On Wed, Apr 10, 2013 at 12:32 AM, Andrej N. Gritsenko <[email protected]> wrote: > Hello! > > PCMan has written on Tuesday, 9 April, at 23:43: >>On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <[email protected]> >>wrote: >>> 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? > > Completely OK! Thank you very much! > >>>>> 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. > > Let's see. The ambiguous names are: > > a) fm_thumbnail_result_cancel() - fm_thumbnail_loader_cancel() is nowhere > used; > b) fm_thumbnail_result_get_*() - fm_thumbnail_loader_get_*() are nowhere > used. > > And the whole fm_thumbnail_loader_* namespace is used only in those > fm-thumbnail-loader.[hc] files and nowhere else, so there could be no > name clashes! And file name fm-thumbnail-loader.[hc] suggests it defines > namespaces fm_thumbnail_loader_* and FmThumbnailLoader*, isn't it? > >>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? > > I still prefer to have single unified fm_thumbnail_loader_* namespace > instead of two - fm_thumbnail_loader_* and fm_thumbnail_result_*. Also it > may be reasonable to change FmThumbnailResult into FmThumbnailLoader and > have namespaces unified to exclude any possible misunderstandings. Does > that look reasonable for you too? > > With the best wishes. > Andriy. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
