From: PCMan <pcm...@gm...> - 2013-03-15 08:12:31
|
Hello, I just finished the rework of thumbnail loading for libfm. The code is in thumbnails branch of libfm repo. git://pcmanfm.git.sourceforge.net/gitroot/pcmanfm/libfm-qt Things changed: 1. Thumbnail loading code is moved from libfm-gtk to libfm and becomes GUI toolkit independent 2. The thumbnails branch of pcmanfm-qt can utilize the new code to load thumbnails in Qt now. If there are no big problems, I'd suggest merge the changes to master branch. Cheers! |
From: PCMan <pcm...@gm...> - 2013-03-16 06:22:57
|
Hello, Since the API/ABIs are not changed, I'd like to ask if it's possible to cherry pick these changes from thumbnails branch, and add them to the last stable release (v1.1) we have. Then, make a minor new release only adding these new APIs? Is this proposal acceptable for you guys? Since we're far from the next major release, I'd like to make this minor addition published earlier. This is currently a major blocker of the Qt port of pcmanfm/libfm which is very close to production use now. Thank you. On Fri, Mar 15, 2013 at 4:12 PM, PCMan <pcm...@gm...> wrote: > Hello, > I just finished the rework of thumbnail loading for libfm. > The code is in thumbnails branch of libfm repo. > git://pcmanfm.git.sourceforge.net/gitroot/pcmanfm/libfm-qt > > Things changed: > 1. Thumbnail loading code is moved from libfm-gtk to libfm and becomes > GUI toolkit independent > 2. The thumbnails branch of pcmanfm-qt can utilize the new code to > load thumbnails in Qt now. > > If there are no big problems, I'd suggest merge the changes to master branch. > > Cheers! |
From: Andrej N. G. <an...@re...> - 2013-03-16 12:45:33
|
Hello! PCMan has written on Saturday, 16 March, at 14:22: >Since the API/ABIs are not changed, I'd like to ask if it's possible >to cherry pick these changes from thumbnails branch, and add them to >the last stable release (v1.1) we have. >Then, make a minor new release only adding these new APIs? >Is this proposal acceptable for you guys? We have decided that 1.1.x will contain only bugfixes, no new APIs or features, otherwise it will make a mess. I'm sorry. >Since we're far from the next major release, I'd like to make this >minor addition published earlier. This is currently a major blocker of >the Qt port of pcmanfm/libfm which is very close to production use >now. As I've proposed in IRC earlier, let it be called not stable release but alpha testing version (which it is really still I suppose) so you can just tell in its INSTALL file that it should be built together with GIT version of libfm. What is bad with that? I hope that libfm-1.2 will be ready for beta release (i.e. with frozen API) somewhere near summer then you can make it beta release based on published version of libfm at that time as well. Just have the Qt port alpha for testing until then. Is that acceptable for you? BTW, 1.2.x is backward compatible with 1.0.x and 1.1.x versions and therefore users can build libfm from GIT to test Qt port and it will not conflict with Gtk version of pcmanfm, in any case. >Thank you. Thank you too. Andriy. |
From: PCMan <pcm...@gm...> - 2013-03-16 16:32:10
|
Well, Depending on a git version of lib is quite bad, especially for packagers. Many packagers avoid packaging git code. This will result in much less users and visibility. The lack of users in turns causes lack of tests to some degree. Many users who can provide useful feedbacks do not know how to use git or cmake at all. So I hope there can be earlier releases & earlier inclusion into some distros. To not break anything, I carefully avoid possible ABI changes and even keep old APIs intact. I did my best and made some effort to keep backward compatibility. Hence I'll be very disappointed if all the effort does not worth even a minor release. I respect the decision of other team members. However personally I think the rule for making releases is a little bit too strict sometimes. It's quite frustrating when you have some nice code which works well but cannot be published. On Sat, Mar 16, 2013 at 8:45 PM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan has written on Saturday, 16 March, at 14:22: >>Since the API/ABIs are not changed, I'd like to ask if it's possible >>to cherry pick these changes from thumbnails branch, and add them to >>the last stable release (v1.1) we have. >>Then, make a minor new release only adding these new APIs? >>Is this proposal acceptable for you guys? > > We have decided that 1.1.x will contain only bugfixes, no new APIs or > features, otherwise it will make a mess. I'm sorry. > >>Since we're far from the next major release, I'd like to make this >>minor addition published earlier. This is currently a major blocker of >>the Qt port of pcmanfm/libfm which is very close to production use >>now. > > As I've proposed in IRC earlier, let it be called not stable release > but alpha testing version (which it is really still I suppose) so you can > just tell in its INSTALL file that it should be built together with GIT > version of libfm. What is bad with that? I hope that libfm-1.2 will be > ready for beta release (i.e. with frozen API) somewhere near summer then > you can make it beta release based on published version of libfm at that > time as well. Just have the Qt port alpha for testing until then. Is that > acceptable for you? > > BTW, 1.2.x is backward compatible with 1.0.x and 1.1.x versions and > therefore users can build libfm from GIT to test Qt port and it will not > conflict with Gtk version of pcmanfm, in any case. > >>Thank you. > > Thank you too. > > Andriy. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Andrej N. G. <an...@re...> - 2013-03-16 17:25:35
|
Hello! PCMan has written on Sunday, 17 March, at 0:32: >Well, >Depending on a git version of lib is quite bad, especially for packagers. >Many packagers avoid packaging git code. Well, I understand that. But yet, use "special package of 1.1" isn't anyhow better. And yet, that "special package of 1.1" is required for quite a short period while we make libfm-1.2 API final. And I thought we have reached agreement that pcmanfm-qt may wait before calling it final (stable) release. And while it's testing, use development branches of any used libraries is quite possible. >This will result in much less users and visibility. >The lack of users in turns causes lack of tests to some degree. >Many users who can provide useful feedbacks do not know how to use git >or cmake at all. Well, they need to know CMake to build pcmanfm-qt right now, don't they? >So I hope there can be earlier releases & earlier inclusion into some distros. Have libfm 1.1.x which isn't really 1.1 but half-1.2 will get anger of every distro maintainer on us. The desision to not put any API changes into 1.1.x after its release (which was before winter) was strictly told by all maintainers on IRC when I've tried to release 1.0.2 - it was said micro versions should be only bugfixes and never ever API changes, or it is a hell to maintain that otherwise. Maintainers blame me that I've put out 1.0.1 which had few new APIs and told me I don't know how to release versions. In short, if we release invalid version of libfm then we should not expect pcmanfm-qt be accepted into distros. :( >To not break anything, I carefully avoid possible ABI changes and even >keep old APIs intact. Adding new public APIs is unfortunately API changes as well and should be appropriately handled by each and every distro. So we cannot release 1.1.1 saying it's bugfix but in real containing new APIs, all distro maintainers will damn us. :( >I did my best and made some effort to keep backward compatibility. >Hence I'll be very disappointed if all the effort does not worth even >a minor release. Yes, it is worth minor release, i.e. 1.2, but unfortunately 1.2 is not fully ready yet. I'll try to finish everything as soon as possible but I'm sorry it's not ready yet. I hope to do it in due April. >I respect the decision of other team members. >However personally I think the rule for making releases is a little >bit too strict sometimes. >It's quite frustrating when you have some nice code which works well >but cannot be published. Well, it's possible package pcmanfm-qt together with current snapshot of libfm for wide testing. As I said already, that will not be much long but only while testing stage. At the time pcmanfm-qt reaches stable final release, there will be libfm 1.2 pre-lelease around so there will be no problems. I'm sad you've missed me on IRC today. I'm sorry that I was busy a bit at that time. :( Thank you very much. Andriy. |
From: Andrej N. G. <an...@re...> - 2013-03-17 00:17:52
|
Hello! PCMan has written on Friday, 15 March, at 16:12: >Hello, >I just finished the rework of thumbnail loading for libfm. >The code is in thumbnails branch of libfm repo. >git://pcmanfm.git.sourceforge.net/gitroot/pcmanfm/libfm-qt >Things changed: >1. Thumbnail loading code is moved from libfm-gtk to libfm and becomes >GUI toolkit independent >2. The thumbnails branch of pcmanfm-qt can utilize the new code to >load thumbnails in Qt now. >If there are no big problems, I'd suggest merge the changes to master branch. That change seems good. There is a problem with it though - it is never scalable despite of being library call. In old thumbnail code there was only one image format and it was unchangeable. New code introduces setup for format but format still left unchangeable! That is invalid design since that static data can be accidentally overwritten. To avoid this problem calls below should be changed: FmThumbnailResult* fm_thumbnail_loader_load(FmFileInfo* src_file, guint size, FmThumbnailResultCallback callback, gpointer user_data); should become FmThumbnailResult* fm_thumbnail_loader_load(FmFileInfo* src_file, GType type, guint size, FmThumbnailResultCallback callback, gpointer user_data); and void fm_thumbnail_loader_set_backend(ThumbnailLoaderBackend* _backend); should become void fm_thumbnail_loader_set_backend(GType type, ThumbnailLoaderBackend* _backend); and therefore we can support more than one image type. And instead of static ThumbnailLoaderBackend backend = {0}; there should be static GSList *backends = NULL; along with few tiny changes in places which are related to that static backend data. And also GType member should be added into ThumbnailTask structure due to that change. 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_*). What do you think about it? Andriy. |
From: PCMan <pcm...@gm...> - 2013-03-18 03:50:36
|
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. For those who really need to use other formats, here are 2 options: 1. Write a backend for GdkPixbuf or Qt/QImage, so all other gtk+ or Qt programs can use it, not just the file manager. (This one is the best because the whole desktop environment can use it, and the work needs to be done is not significantly more than making it work with libfm only) 2. Do type checking in backend functions yourself like this: GObject* scale_image(GObject* source, ...) { GType src_type = G_OBJECT_TYPE(source); if(src_type == GDK_TYPE_PIXBUF) { } else if(src_type == OTHER_TYPE) { } return NULL; } In this way, programs which really need so complicated design can still use multiple formats. The type checking is done in the backend functions by themselves, not libfm. I think this is more than enough. The idea behind this design is, libfm does not need to know the format of the image objects. To libfm, they're only memory blocks with reference-counting. That's all. Libfm is only responsible for locating the thumbnails and reading the image file stream. It handles I/O and caching, but knows nothing about the implementation details of the GUI parts. The code in fm-thumbnail-loader.c is already messy, and I really think that KISS is better. We don't need to mess with the implementation details in the GUI libraries. When I designed libfm, it's not intended to be used with mixing different GUI toolkits in one single application. Most of the time we only use one GUI toolkit at a time and your GUI toolkit normally only recognizes one image format, so I think one backend is enough. If multiple formats is required, type checking can be done inside backend functions. Thanks. On Sun, Mar 17, 2013 at 8:17 AM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan has written on Friday, 15 March, at 16:12: >>Hello, >>I just finished the rework of thumbnail loading for libfm. >>The code is in thumbnails branch of libfm repo. >>git://pcmanfm.git.sourceforge.net/gitroot/pcmanfm/libfm-qt > >>Things changed: >>1. Thumbnail loading code is moved from libfm-gtk to libfm and becomes >>GUI toolkit independent >>2. The thumbnails branch of pcmanfm-qt can utilize the new code to >>load thumbnails in Qt now. > >>If there are no big problems, I'd suggest merge the changes to master branch. > > That change seems good. There is a problem with it though - it is > never scalable despite of being library call. In old thumbnail code there > was only one image format and it was unchangeable. New code introduces > setup for format but format still left unchangeable! That is invalid > design since that static data can be accidentally overwritten. To avoid > this problem calls below should be changed: > > FmThumbnailResult* fm_thumbnail_loader_load(FmFileInfo* src_file, > guint size, > FmThumbnailResultCallback callback, > gpointer user_data); > > should become > > FmThumbnailResult* fm_thumbnail_loader_load(FmFileInfo* src_file, > GType type, guint size, > FmThumbnailResultCallback callback, > gpointer user_data); > > and > > void fm_thumbnail_loader_set_backend(ThumbnailLoaderBackend* _backend); > > should become > > void fm_thumbnail_loader_set_backend(GType type, ThumbnailLoaderBackend* _backend); > > and therefore we can support more than one image type. And instead of > > static ThumbnailLoaderBackend backend = {0}; > > there should be > > static GSList *backends = NULL; > > along with few tiny changes in places which are related to that static > backend data. And also GType member should be added into ThumbnailTask > structure due to that change. > > 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_*). > > What do you think about it? > > Andriy. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Andrej N. G. <an...@re...> - 2013-04-08 15:33:02
|
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? >> 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_*). >> 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. |
From: PCMan <pcm...@gm...> - 2013-04-09 15:43:31
|
On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <an...@re...> 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 > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Andrej N. G. <an...@re...> - 2013-04-09 16:32:54
|
Hello! PCMan has written on Tuesday, 9 April, at 23:43: >On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <an...@re...> 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. |
From: PCMan <pcm...@gm...> - 2013-04-10 02:52:54
|
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 <an...@re...> wrote: > Hello! > > PCMan has written on Tuesday, 9 April, at 23:43: >>On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <an...@re...> 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 > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Andrej N. G. <an...@re...> - 2013-04-10 21:59:49
|
Hello! PCMan has written on Wednesday, 10 April, at 10:52: >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. :-( Unfortunately I was too much busy today as well. Sure, I can do it. I think I'll have some time tomorrow. >On Wed, Apr 10, 2013 at 12:32 AM, Andrej N. Gritsenko [.......] >> may be reasonable to change FmThumbnailResult into FmThumbnailLoader and >> have namespaces unified to exclude any possible misunderstandings. Does >> that look reasonable for you too? I would like to hear your opinion on this too. Thank you very much! Andriy. |
From: PCMan <pcm...@gm...> - 2013-04-10 23:52:21
|
On Thu, Apr 11, 2013 at 5:59 AM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan has written on Wednesday, 10 April, at 10:52: >>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. :-( > > Unfortunately I was too much busy today as well. Sure, I can do it. I > think I'll have some time tomorrow. > >>On Wed, Apr 10, 2013 at 12:32 AM, Andrej N. Gritsenko > [.......] >>> may be reasonable to change FmThumbnailResult into FmThumbnailLoader and >>> have namespaces unified to exclude any possible misunderstandings. Does >>> that look reasonable for you too? > > I would like to hear your opinion on this too. Sure, please do it. I remembered that why I did not use that name. I tried multi-backend approach in my own branch and that name is used somewhere. Later I found it too complicated and dropped that branch. I forgot that in the current branch that name is unused. Feel free to do the rename. Thanks! > Thank you very much! > Andriy. |
From: Andrej N. G. <an...@re...> - 2013-04-12 09:53:49
|
Hello! PCMan has written on Thursday, 11 April, at 7:52: >On Thu, Apr 11, 2013 at 5:59 AM, Andrej N. Gritsenko <an...@re...> wrote: >> PCMan has written on Wednesday, 10 April, at 10:52: >>>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. :-( >> >> Unfortunately I was too much busy today as well. Sure, I can do it. I >> think I'll have some time tomorrow. >> >>>On Wed, Apr 10, 2013 at 12:32 AM, Andrej N. Gritsenko >> [.......] >>>> may be reasonable to change FmThumbnailResult into FmThumbnailLoader and >>>> have namespaces unified to exclude any possible misunderstandings. Does >>>> that look reasonable for you too? >> >> I would like to hear your opinion on this too. >Sure, please do it. >I remembered that why I did not use that name. >I tried multi-backend approach in my own branch and that name is used somewhere. >Later I found it too complicated and dropped that branch. >I forgot that in the current branch that name is unused. >Feel free to do the rename. >Thanks! All done, everything is in master branch now. I've fixed a little problem with multithreaded variable access while I did the changes. Thanks. Andriy. |