@bdillahu: I've updated svn (r20290) which hopefully fixes the issue. It seems to work for me. http://www.timalmdal.com
hebhansen
Joined: 2009-02-10
Posts: 573
Posted: Fri, 2009-03-06 08:24
Upload of images:
1) Using the tab at the top and adding photos executes the Flash uploader and multiple files may be chosen. This upload does not work here. Not for one file or multiple files.
- The status bar is updated
- 100% ends up with Complete
- I click finish
and there are no photos, no nothing
2) Uploading via the black dropdown on top of an album works fine, but it does not go through the flash-uploader. However, I am only able to chose 1 image at a time...
In other words. Flash upload does not work
The other works
I am using Internet Explorer 7.0-5730.13
all the best
HB
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Sun, 2009-03-08 00:14
I'm unable to reproduce the issue with Flash uploader. But we're going to rework that in the next release, so try again after that change is in and we'll see if that fixed it.
hebhansen
Joined: 2009-02-10
Posts: 573
Posted: Thu, 2009-03-12 14:11
Reading through comments and requests for G3 I get feeling that this is becoming a wishing well as was the case for G2
I truly believe in your concept of keeping a simple Gallery Core with smooth API and leaving it to others to contribute with modules.
However, IMO some of the functions concidered for G3, are they justified for a core platform? Functions are great and we all need them. But adding new nice to have functions to the Core G3 will add to the complexity when upgrading etc.
Keep it simple! and why is that?
Let us compare G3 as a stand-alone platform to fx. Drupal
Drupal Core has what it takes to setup a lean-mean production site. Installation is incredibly smooth because of a standardized core with no nice to have stuff around that has evolved to the current Drupal 6.10.
What Drupal does is:
Update tracking:
- gathering updates at drupal.org in an organized way. Drupal core has a built in function that checks for updates on drupal.org on core and all installed ad-on modules. You are notified and you do not have to browse around for news. http://drupal.org/project/modules
Development is distributed effectively and you have loads of modules to chose from.
What to add:
- Drupal offers a very nice site for picking your ad-on modules. Modules are reviewed and graded to give you an indication wether a module is obsolete. Contributors are numerous, hence, providing a very dynamic community, made possible by simple core and strict API. Following is a search for top-rated modules: http://drupalmodules.com/top-rated
Multilanguage:
The constant development of Drupal Core and Modules makes it difficult to keep up with translation. Drupal has assigned translators around the world. They are setting up a project that allows translators to translate on-the-fly during administration of their own sites. Translations are dynamically collected at drupal.org and then included for everyones next upgrade.
the advantage to a strict Gallery core system is that the core will survive new generations. Making it worthwhile to create modules and translations for the API and the core. Everyone gets the Gallery one needs and not everything else.
My issue here is that:
Face detection
Gmaps
etc
is already part of the Gallery Core - I am wondering if Gallery 3 is heading towards the same misunderstanding that G2 did???
Personally I would want both face-detection and Gmaps, however, are these modules justified in core? In my opinion they are not. And it seems that Gallery is about to include nic to have as opposed to need to have for this to be the platform of choise for most people and keeping integration to modules and the world around as simple as possible.
all the best
HB
talmdal
Joined: 2006-12-06
Posts: 358
Posted: Thu, 2009-03-12 14:44
@hebhansen: +1. I agree that we have to be able to careful about expanding core to include the kitchen sink. I believe (or hope) once we build the interface that creates a module repository, things like gmap, face recognition, etc will get pulled from the core distribution and put in a non core module repository.
I also think we have already too much in core. I strongly believe that core should have no external dependencies.
1) piclens is a nice slideshow, but it is external. G3 should have its own basic javascript slideshow which doesn't have a external dependency.
2) face recognition... nice concept does it belong in core... i don't thinks so
3) gravatar's another external interface, it should be in a module by itself.
Don't get me wrong, I like how G3 is shaping up, and look forward to converting to it. I'm just a strong believer in less is more.
One of the things that need to be in place to really make this work well is a module dependency api.
Concerning viewing of content I thing G3 should concider Lightbox2. the modules is designed for Drupal and is capable of displaying:
Images
group Images (Manual forward)
Slideshow (Auto forward)
Video (Local or URL content from Youtube, Google..)
Iframes (Links to external sites open in a Ligtbox. You can navigate in the Lightbox. When leaving you are back in "my" site)
The lightbox2 module and a lot of nice code is already available.
In my book this feature is so show-off great that it could easily qualify for Core
all the best
HB
yeahy
Joined: 2008-11-07
Posts: 69
Posted: Thu, 2009-03-12 19:28
@talmdal, @hebhansen:
The slideshow within Gallery2 Image Chooser (http://gallery.menalto.com/forum/94) runs smoother than the default slideshow module in my site, maybe it's because the image chooser only loads the resizes photos, very prompt, the user experience is better than the default module and it doesn't need piclens.
Rooting less is more.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2009-03-13 04:16
@hebhansen There is code in svn right now that will probably not be part of the official distribution. The Google maps and Polar Rose modules are in there because they were very easy to write and were good proof of concepts for what we want modules to be able to do. They will probably not be part of the final offical release. Instead we would like to move towards a model having this code developed and supported by the community and easily available for download (as Drupal does). I disagree about Gravatar support-- this is about 5 lines of code. There's a cost/benefit decision to be made, and in this case I felt that gravatar support was cheap enough that we should put it into the core to make the product better. You can convince me otherwise, though I could see Lightbox2 as a theme, but somebody will have to spend the time to implement it well. Right now we're still focused on getting our one existing theme up to the level where we want it.
@yeahy I'm confused. G2 Image Chooser isn't a slideshow as far as I can tell from the demos. What are you suggesting?
yeahy
Joined: 2008-11-07
Posts: 69
Posted: Fri, 2009-03-13 09:05
@bharat: I suggest to reduce the loading time. The slideshow module in G2 is one of the favorite modules, the effect is great, but it needs so much time before show something.
In my site, when the users click the "view slideshow" link, the screen becomes black at once. Then it needs about 10-15 seconds to load something(the piclens?). Then you will see snap1. Then after about 30 seconds stay with snap1, you will see the snap2, the photo slide show. So it means the users will wait about 40-45s before they see the slideshow. Yes, if the user go to another album, view slideshow again, they needn't wait so long.
As to the Image chooser, when the users choose the photos to insert, if they click the "magnifier" link over each photo(snap4), a small slideshow will popup as snap3. It's very simple, it seems it only load the resize but not the full size photos, have no fantasic effects as default slide show module, but it's fast, normally after 3 seconds, the users can see the show.
So if the default slideshow module only cost 3 seconds to init, that will be perfect.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2009-03-13 21:11
@yeahy that makes sense. I think that the problem is that CoolIris loads the overly-large full size image which is slow. It really should load the resize first, then replace that with the full size.. it would be way faster. To figure out whether this is an issue because of the full size, let's try taking the full sizes out of your media RSS feed. To do that, edit modules/slideshow/views/feed.mrss.php and find/delete this block (around line 62):
I'm finding in my Gallery that there's still a delay in the CoolIris code.. what do you think? I'll follow up with the CoolIris folks to see if they can speed this up.
yeahy
Joined: 2008-11-07
Posts: 69
Posted: Sun, 2009-03-15 10:42
@bharat Thanks for the solution. It does help, way faster. I can't find modules/slideshow/views/feed.mrss.php but modules\slideshow\templates\SlideshowMediaRss.tpl in my instance (Gallery 2.3). So I remove a similar block. And modify modules\slideshow\classes\SlideshowHelper.class.
/* origin:
list ($ret, $preferredFullImages) = GalleryCoreApi::fetchPreferredsByItemIds($childIds); */
list ($ret, $preferredFullImages) = GalleryCoreApi::fetchResizesByItemIds($childIds);
I'm finding in my Gallery that there's still a delay in the CoolIris code.. what do you think?
Maybe CoolIris is trying to load everything which cause slow. E.g. I don't need CoolIris to load the 'Cool3D'(on the top right corner of the slideshow). After implement the mod above, no Cool3D anymore.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Mon, 2009-03-16 03:19
I pinged the CoolIris folks, we'll see what they can come up with.
alexandreracine
Joined: 2005-06-16
Posts: 39
Posted: Mon, 2009-03-16 04:01
There seems to be no way of putting a bug report. So Bharat, you seems to be checking this post right?
First of, nice work! So far so good.
After playing with it 20 minutes...
bug 1 : I added a picture, but my camera seems to like .JPG instead of .jpg, so I had to rename the files for the "add" button to see the pictures.
bug 2 : If I add pictures on the root folder, some icons are present when the mouse is over the picture, like "move to other album", but the icons are not there on a picture inside an album?. Sorry, I was actually logout for no reason. I can't retrace that.
bug 3 : Why do we have to put a name and a title for album creation? This is the kind of questions a user might ask. It's probably like G2, it's for the folder name, but why G3 would not create that without user intervention? A number would do or something like [filtered_title]_number_date_random or something like that. Out of sight, out of mind. It could still be visible as information for admins.
bug? 4 : The search does not search in filenames. For example, one photo is IMG_2540.jpg, so I searched for "2540" and no result. And yes this is after indexing everything
@Bharat : #3 - I would put nothing for all the users. The folder name would be auto-generated for everybody and hidden in the creation album process. No confusion, no problem, all auto. The admin would see "Folder name" instead of "Name" and "Album title" in the property of the album so he could do maintenance or watever he wants with it, or watever G3 plans are
In some way, just like Drupal does. Some people could even do a module to customize all those paths, à la Drupal just like pathauto http://drupal.org/project/pathauto
@alexandreracine: good feedback. We had discussed it when we started the redesign and had felt at the time, that it was important for users to be able to look in the image storage directory and find their images because the image store matched the album heirarchy. Good to hear a counter point.
I fully understand you are cought up in other issues right now. No rush
all the best
HB
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Wed, 2009-03-18 02:18
I know what lightbox is, I'm just curious to see how you're going to reliably implement it across all themes since it changes functionality that's typically wholly controlled by the theme. I'll wait and see
alexandreracine
Joined: 2005-06-16
Posts: 39
Posted: Wed, 2009-03-18 20:18
@talmdal : Thanks. Just to be sure, When I am talking about "users", I am talking about every users that would use G3 except for admins. So "user" = joejoe and "admin"=root is you want to compare with Linux. That said, "users" would never see the real "folder name", only admins. "Users" don't need to go in the files, they just want to use their albums
I wasn't going to reply but I installed G3 alpha 3 and my sentiment only got stronger.
I don't know what kind of a break you want from me. I was not saying much about the features of G3 but merely stating the obvious that it has _nothing_ to do with G2 and should, hence, be called something different. F1, perhaps, to emphasize the fact that it is inferior to G2. Heck, moving it to a completely different website might also help.
Because implying that they have anything in common is a gross misleading, at the very least.
On the other hand, what is the future of our beloved G2? Given a choice, I would stick to that and have no interest in what currently is being called G3. I apologize if this information is anywhere on the web site. I just can't find it at the moment.
shtegtari
Joined: 2006-07-31
Posts: 11
Posted: Sun, 2009-04-05 16:32
My latest post (Sun, 2009-04-05 16:27) was in response to the one of talmdal, of Tue, 2009-02-24 23:57.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Sun, 2009-04-05 17:35
@shtegari I'm curious to hear what you consider to be inferior about Gallery 3. Is it merely a lack of features? Or is there some other, more fundamental problem? By the way, to continue your car analogy, "Gallery" is the brand and "3" is the model. Ford doesn't rename their company when they put out a new car. We're not renaming our brand. As for Gallery 2, the code is readily available to all so while the core dev team is not going to be doing much (if any) more work on it, any interested party can work on it. Now would be a great time to fork it, create a new website and start getting some traction. Let us know how it goes and we'll give you some support (as we did with Jallery, the fork of Gallery 1).
JohnnyC
Joined: 2006-08-22
Posts: 22
Posted: Thu, 2009-04-23 17:34
Where can I find more details on the Gallery3 API? The documentation for this (Gallery3:API:REST) seems to be incomplete.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2009-04-24 00:04
@JohnnyC: we don't have a lot of docs for it currently. They're coming, but they'll take a little while.
Posts: 358
@bdillahu: I've updated svn (r20290) which hopefully fixes the issue. It seems to work for me.
http://www.timalmdal.com
Posts: 573
Upload of images:
1) Using the tab at the top and adding photos executes the Flash uploader and multiple files may be chosen. This upload does not work here. Not for one file or multiple files.
- The status bar is updated
- 100% ends up with Complete
- I click finish
and there are no photos, no nothing
2) Uploading via the black dropdown on top of an album works fine, but it does not go through the flash-uploader. However, I am only able to chose 1 image at a time...
In other words. Flash upload does not work
The other works
I am using Internet Explorer 7.0-5730.13
all the best
HB
Posts: 7994
I'm unable to reproduce the issue with Flash uploader. But we're going to rework that in the next release, so try again after that change is in and we'll see if that fixed it.
Posts: 573
Reading through comments and requests for G3 I get feeling that this is becoming a wishing well as was the case for G2
I truly believe in your concept of keeping a simple Gallery Core with smooth API and leaving it to others to contribute with modules.
However, IMO some of the functions concidered for G3, are they justified for a core platform? Functions are great and we all need them. But adding new nice to have functions to the Core G3 will add to the complexity when upgrading etc.
Keep it simple! and why is that?
Let us compare G3 as a stand-alone platform to fx. Drupal
Drupal Core has what it takes to setup a lean-mean production site. Installation is incredibly smooth because of a standardized core with no nice to have stuff around that has evolved to the current Drupal 6.10.
What Drupal does is:
Update tracking:
- gathering updates at drupal.org in an organized way. Drupal core has a built in function that checks for updates on drupal.org on core and all installed ad-on modules. You are notified and you do not have to browse around for news.
http://drupal.org/project/modules
Development is distributed effectively and you have loads of modules to chose from.
What to add:
- Drupal offers a very nice site for picking your ad-on modules. Modules are reviewed and graded to give you an indication wether a module is obsolete. Contributors are numerous, hence, providing a very dynamic community, made possible by simple core and strict API. Following is a search for top-rated modules:
http://drupalmodules.com/top-rated
Multilanguage:
The constant development of Drupal Core and Modules makes it difficult to keep up with translation. Drupal has assigned translators around the world. They are setting up a project that allows translators to translate on-the-fly during administration of their own sites. Translations are dynamically collected at drupal.org and then included for everyones next upgrade.
the advantage to a strict Gallery core system is that the core will survive new generations. Making it worthwhile to create modules and translations for the API and the core. Everyone gets the Gallery one needs and not everything else.
My issue here is that:
Face detection
Gmaps
etc
is already part of the Gallery Core - I am wondering if Gallery 3 is heading towards the same misunderstanding that G2 did???
Personally I would want both face-detection and Gmaps, however, are these modules justified in core? In my opinion they are not. And it seems that Gallery is about to include nic to have as opposed to need to have for this to be the platform of choise for most people and keeping integration to modules and the world around as simple as possible.
all the best
HB
Posts: 358
@hebhansen: +1. I agree that we have to be able to careful about expanding core to include the kitchen sink. I believe (or hope) once we build the interface that creates a module repository, things like gmap, face recognition, etc will get pulled from the core distribution and put in a non core module repository.
I also think we have already too much in core. I strongly believe that core should have no external dependencies.
1) piclens is a nice slideshow, but it is external. G3 should have its own basic javascript slideshow which doesn't have a external dependency.
2) face recognition... nice concept does it belong in core... i don't thinks so
3) gravatar's another external interface, it should be in a module by itself.
Don't get me wrong, I like how G3 is shaping up, and look forward to converting to it. I'm just a strong believer in less is more.
One of the things that need to be in place to really make this work well is a module dependency api.
http://www.timalmdal.com
Posts: 573
Concerning viewing of content I thing G3 should concider Lightbox2. the modules is designed for Drupal and is capable of displaying:
Images
group Images (Manual forward)
Slideshow (Auto forward)
Video (Local or URL content from Youtube, Google..)
Iframes (Links to external sites open in a Ligtbox. You can navigate in the Lightbox. When leaving you are back in "my" site)
Very cool - Demo site here
http://www.stellapower.net/lightbox2
The lightbox2 module and a lot of nice code is already available.
In my book this feature is so show-off great that it could easily qualify for Core
all the best
HB
Posts: 69
@talmdal, @hebhansen:
The slideshow within Gallery2 Image Chooser (http://gallery.menalto.com/forum/94) runs smoother than the default slideshow module in my site, maybe it's because the image chooser only loads the resizes photos, very prompt, the user experience is better than the default module and it doesn't need piclens.
Rooting less is more.
Posts: 7994
@hebhansen There is code in svn right now that will probably not be part of the official distribution. The Google maps and Polar Rose modules are in there because they were very easy to write and were good proof of concepts for what we want modules to be able to do. They will probably not be part of the final offical release. Instead we would like to move towards a model having this code developed and supported by the community and easily available for download (as Drupal does). I disagree about Gravatar support-- this is about 5 lines of code. There's a cost/benefit decision to be made, and in this case I felt that gravatar support was cheap enough that we should put it into the core to make the product better. You can convince me otherwise, though I could see Lightbox2 as a theme, but somebody will have to spend the time to implement it well. Right now we're still focused on getting our one existing theme up to the level where we want it.
@yeahy I'm confused. G2 Image Chooser isn't a slideshow as far as I can tell from the demos. What are you suggesting?
Posts: 69
@bharat: I suggest to reduce the loading time. The slideshow module in G2 is one of the favorite modules, the effect is great, but it needs so much time before show something.
In my site, when the users click the "view slideshow" link, the screen becomes black at once. Then it needs about 10-15 seconds to load something(the piclens?). Then you will see snap1. Then after about 30 seconds stay with snap1, you will see the snap2, the photo slide show. So it means the users will wait about 40-45s before they see the slideshow. Yes, if the user go to another album, view slideshow again, they needn't wait so long.
As to the Image chooser, when the users choose the photos to insert, if they click the "magnifier" link over each photo(snap4), a small slideshow will popup as snap3. It's very simple, it seems it only load the resize but not the full size photos, have no fantasic effects as default slide show module, but it's fast, normally after 3 seconds, the users can see the show.
So if the default slideshow module only cost 3 seconds to init, that will be perfect.
Posts: 7994
@yeahy that makes sense. I think that the problem is that CoolIris loads the overly-large full size image which is slow. It really should load the resize first, then replace that with the full size.. it would be way faster. To figure out whether this is an issue because of the full size, let's try taking the full sizes out of your media RSS feed. To do that, edit modules/slideshow/views/feed.mrss.php and find/delete this block (around line 62):
I'm finding in my Gallery that there's still a delay in the CoolIris code.. what do you think? I'll follow up with the CoolIris folks to see if they can speed this up.
Posts: 69
@bharat Thanks for the solution. It does help, way faster. I can't find modules/slideshow/views/feed.mrss.php but modules\slideshow\templates\SlideshowMediaRss.tpl in my instance (Gallery 2.3). So I remove a similar block. And modify modules\slideshow\classes\SlideshowHelper.class.
Then the 30s of 45s waiting time dispeared.
Posts: 69
Maybe CoolIris is trying to load everything which cause slow. E.g. I don't need CoolIris to load the 'Cool3D'(on the top right corner of the slideshow). After implement the mod above, no Cool3D anymore.
Posts: 7994
I pinged the CoolIris folks, we'll see what they can come up with.
Posts: 39
There seems to be no way of putting a bug report. So Bharat, you seems to be checking this post right?
First of, nice work! So far so good.
After playing with it 20 minutes...
bug 1 : I added a picture, but my camera seems to like .JPG instead of .jpg, so I had to rename the files for the "add" button to see the pictures.
bug 2 :
If I add pictures on the root folder, some icons are present when the mouse is over the picture, like "move to other album", but the icons are not there on a picture inside an album?. Sorry, I was actually logout for no reason. I can't retrace that.bug 3 : Why do we have to put a name and a title for album creation? This is the kind of questions a user might ask. It's probably like G2, it's for the folder name, but why G3 would not create that without user intervention? A number would do or something like [filtered_title]_number_date_random or something like that. Out of sight, out of mind. It could still be visible as information for admins.
bug? 4 : The search does not search in filenames. For example, one photo is IMG_2540.jpg, so I searched for "2540" and no result. And yes this is after indexing everything
Can't wait for G3A3 ;)
Alexandre Racine
http://www.salsamontreal.com - Évènement, photos et beaucoup plus!
Posts: 7994
@alexandreracine bug #1 is fixed in alpha 3. bug #3 -- I agree.. we should have a better name for that. Suggestions? bug #4 -- I agree. I've filed that as https://apps.sourceforge.net/trac/gallery/ticket/145
Thanks for the feedback!
Posts: 39
@Bharat : #3 - I would put nothing for all the users. The folder name would be auto-generated for everybody and hidden in the creation album process. No confusion, no problem, all auto. The admin would see "Folder name" instead of "Name" and "Album title" in the property of the album so he could do maintenance or watever he wants with it, or watever G3 plans are
In some way, just like Drupal does. Some people could even do a module to customize all those paths, à la Drupal just like pathauto http://drupal.org/project/pathauto
I'll wait for alpha 3
Alexandre Racine
http://www.salsamontreal.com - Évènement, photos et beaucoup plus!
Posts: 358
@alexandreracine: good feedback. We had discussed it when we started the redesign and had felt at the time, that it was important for users to be able to look in the image storage directory and find their images because the image store matched the album heirarchy. Good to hear a counter point.
Tim
http://www.timalmdal.com
Posts: 573
Lightbox2 is not a theme, it runs across themes. It is triggered in the HTML <a> tag using attributes such as:
rel="lightbox", rel="lightgroup[gallery1]", rel="lightshow[gallery2]", rel="lightvideo", rel="lightframe", rel="lightmodal"
I may also be triggered by classes.
From the admin you can specify where to trigger and where not to trigger.
Some work has been done:
http://codex.gallery2.org/Gallery2:Modules:Lightbox
http://codex.gallery2.org/Gallery2:Lightbox_JS_Tutorial
I fully understand you are cought up in other issues right now. No rush
all the best
HB
Posts: 7994
I know what lightbox is, I'm just curious to see how you're going to reliably implement it across all themes since it changes functionality that's typically wholly controlled by the theme. I'll wait and see
Posts: 39
@talmdal : Thanks. Just to be sure, When I am talking about "users", I am talking about every users that would use G3 except for admins. So "user" = joejoe and "admin"=root is you want to compare with Linux. That said, "users" would never see the real "folder name", only admins. "Users" don't need to go in the files, they just want to use their albums
Alexandre Racine
http://www.salsamontreal.com - Évènement, photos et beaucoup plus!
Posts: 7994
Posts: 11
I wasn't going to reply but I installed G3 alpha 3 and my sentiment only got stronger.
I don't know what kind of a break you want from me. I was not saying much about the features of G3 but merely stating the obvious that it has _nothing_ to do with G2 and should, hence, be called something different. F1, perhaps, to emphasize the fact that it is inferior to G2. Heck, moving it to a completely different website might also help.
Because implying that they have anything in common is a gross misleading, at the very least.
On the other hand, what is the future of our beloved G2? Given a choice, I would stick to that and have no interest in what currently is being called G3. I apologize if this information is anywhere on the web site. I just can't find it at the moment.
Posts: 11
My latest post (Sun, 2009-04-05 16:27) was in response to the one of talmdal, of Tue, 2009-02-24 23:57.
Posts: 7994
@shtegari I'm curious to hear what you consider to be inferior about Gallery 3. Is it merely a lack of features? Or is there some other, more fundamental problem? By the way, to continue your car analogy, "Gallery" is the brand and "3" is the model. Ford doesn't rename their company when they put out a new car. We're not renaming our brand. As for Gallery 2, the code is readily available to all so while the core dev team is not going to be doing much (if any) more work on it, any interested party can work on it. Now would be a great time to fork it, create a new website and start getting some traction. Let us know how it goes and we'll give you some support (as we did with Jallery, the fork of Gallery 1).
Posts: 22
Where can I find more details on the Gallery3 API? The documentation for this (Gallery3:API:REST) seems to be incomplete.
Posts: 7994
@JohnnyC: we don't have a lot of docs for it currently. They're coming, but they'll take a little while.