Random Image
Gallery 3.0 Alpha 2 is ready!
Submitted by bharat on Tue, 2009-02-24 05:44
Three weeks ago we released Gallery 3.0 Alpha 1 and we're happy to say that the response has been overwhelmingly positive. Many of you have given great feedback about the features that you'd like to see in the product and we've been hard at work trying to get the product ready for release. For those of you who used Alpha 1, you can see that there are still plenty of things that we need to improve. To reward you for your patience and give you a taste of what's to come, we're releasing Alpha 2 which has significant improvements!
Intended audience
The Alpha 2 release is still intended for enthusiasts, designers and module developers. This is the right time to do a test drive with the improved user interface and to start developing feature extensions and designing new themes.
Note there is still no upgrade path from Gallery 2 to Gallery 3, nor is there an upgrade path from Alpha 1 to Alpha 2. Yes, that's all coming but no, it hasn't been a high enough priority yet.
Security warning
This is a technology preview of Gallery 3.0 and as such it is not intended to be installed on public websites yet. The application is currently undergoing a professional security audit yet but it may have serious security vulnerabilities. Please resist the temptation to share your test drive with the world and wait for the final release first!
OK OK let me try it already!
With the disclaimers and warnings out of the way, here it is: Download Gallery 3.0 Alpha 2 (1.3 MB) .
The Gallery 3 Philosophy
Let's have a closer look at Gallery 3.0 to see why it's so much easier and more fun to customize and extend Gallery 3.0 and how our user centric development process ensures that the user interface is not an afterthought.
-
Scope and target audience - Before starting development on Gallery 3.0, the target audience and the scope of the application have been clearly defined. Gallery 3 is not a general purpose web application handling any file format you throw at it. And it's not supported on every web platform that exists.
Prudent decisions helped to simplify the product at a very early stage. For instance, there are no longer item-level permissions. Permissions are managed on an album level. This simplified many aspects, from the database, over scalability, up to the user interface.
-
Simple to use - We're glad to have usability and user interface experts on our team, designing and prototyping interfaces that just make sense, avoiding the dreaded text deserts and putting Emphasis is on making simple, frequent tasks quick and easy. To see an example of this, check out the admn dashboard and the user/group administration page.
-
Size matters - Gallery 3.0 is currently a mere 3.5MB (uncompressed on your disk), with all its features. Compare that to the 16.5MB of Gallery 2.3's bare bones minimal package. Leaving out some levels of abstraction really helps to lose some weight!
-
On the shoulders of giants... - Gallery 3.0 wouldn't be possible without the great advances of recent years.
-
Gallery 3.0 is built on top of Kohana, a PHP 5 framework that makes PHP application development a breeze. Kudos to the folks from Kohana for their support and for providing this first class application framework!
-
Kohana's prowess in elegance and simplicity couldn't be achieved without the vast improvements of PHP 5 over PHP 4. We're glad we can finally seize the full power of PHP 5. Adios, PHP 4!
-
Remember the days before jQuery? We don't want to look back either :-) It has never easier to add interactivity, AJAX or other custom behaviors to your user interface than it is with jQuery. We use jQuery and jQuery UI widely and UI development couldn't be more hassle-free.
-
-
Simple to customize - Gone are the days of learning 4 different languages (HTML, JavaScript, Smarty, PHP), many different APIs (theme and core API, Gallery 2 smarty tags) and 10 step tutorials to create your own theme. With Gallery 3, you can create your own theme just by copying an existing theme to a new folder. No further changes necessary to make it work. How's that for easy? There's no templating language to learn other than HTML and PHP.
-
Simple to extend - We've exercised great restraint in keeping things simple and it shows in the small size of existing modules. For instance, it takes a small fraction of the code to create a slideshow or comments module for Gallery 3 than it took to implement the same feature set in Gallery 2.
-
Supported configurations - Gallery 3 is supported on Linux / Unix servers, running a MySQL 5 and an Apache 2.2 web server with PHP 5.2. Emphasis on supported, not necessarily required. It may well work with MySQL 4.1 on MS Windows as well, but the Gallery team is going to focus its energy on making the best possible product on the supported configurations.
Currently Implemented Features
The following features are implemented and functioning at varying levels:
- A simpler and powerful Flash based upload UI (we're still tinkering with this!) (new in alpha 2)
- Reset / forgot password mechanism (new in alpha 2)
- Localized UI with built-in editor (server side support is not finished) (new in alpha 2)
- RSS feed for comments (new in alpha 2)
- RSS feed for new images or movies (new in alpha 2)
- EXIF read support (new in alpha 2)
- Import photos from the local webserver (new in alpha 2)
- Support for uploading and viewing FLV movie files (new in alpha 2)
- Ability to view full size photos (new in alpha 2)
- Boolean and full text search (new in alpha 2)
- Album browsing
- Item commenting, comment moderation
- Spam protection with Akismet and Recaptcha
- Image toolkit support for ImageMagick, GD, and GraphicsMagick
- Theme system, including separate admin theme.
- Module system to extend the functionality, and a series of existing modules
- Basic metadata boolean search with relevance ranking
- Flash-powered slideshow (Cooliris)
- Album media RSS feeds
- Quick edits of item metadata
- In place item deletion and rotation
- User group management (drag & drop interface)
- Basic user permission management
- Admin dashboard with drag and drop blocks
Missing Key Features
These features are yet to be added and will be part of the final 3.0 release:
- Bulk editing of albums and photos
- A migration path from Gallery 2
- An image block for your Gallery or external pages
- Improved permissions UI.
- Basic embedding hooks / instructions
- (opt-in) Stats collection (helps us to improve the product)
Roadmap
Gallery 3.0 is undergoing a professional security audit from our good friends over at Gotham Digital Science. They're going to dissect the code and probe it for security vulnerabilities, then report back to us. We'll fix it all up to be safe and sound before shipping out the final release to you. Your security is important to us!
You can track development on our Trac roadmap and if you can't wait for the next public release, you can track the code via our Subversion repository .
Got feedback?
If you have any overall feedback, please visit the Gallery 3.0 Alpha 2 Feedback forum topic and let us know! If you have questions, please visit the Gallery 3 Wiki, the future home for Gallery 3 documentation.
WOO HOO!
Can't wait to upgrade my gallery to G3!
--
www.johndbritton.com
All very exciting. I currently use Gallery2 to in a gallery of audio recordings using the mp3audio module, is there any chance that something similar will be included in Gallery3 or should I approach the module author directly?
www.martinpaling.com
Just out of curiosity, why is a Flash-based uploader being used in a free software application? WordPress has also gone this route, and it is the default uploader. For someone not having Flash installed on his system (like me), this is a step backwards rather than one forward.
With all the technology around AJAX that exists, couldn't a simpler uploading using web standards have been implemented, rather than going to proprietary technology?
Basilgohar: I agree!
Nice to see all the new features!! Local import is a bit shaky though. I tried twice to import a folder with 7 pics. First time only the first pic got imported. Second time three pics got imported. I have imported the same folder with G2 and it worked fine there.
I agree: Flash is not progress, especially when chosen over Java.
Flash is far more-proprietary and available for a subset of the platforms that Java is. Including my primary platform. I do not welcome this shift at all. It sends the wrong message to the rest of the web community.
There's enough suffering from people on OSes and devices lacking Flash as it is, which prompts no end to the reiteration that Flash is a Bad Thing for the web as a whole, especially when there are better cross-platform alternatives. The more websites and projects that vote on the side of using Flash, the more you contribute to the degradation of quality of the internet and give Adobe more control as gatekeeper of who can use the internet, and who can't.
Use DHTML, or Java, or don't do it at all.
When upgrade to G3, will the id(G2: item table, id field; G3: items table id field) field keep the original value? Or will we have a mapping table?
Because we're using some other CMS to integrate G2 and use the id to get the photo, if the id will be changed, we need a mapping, thanks.
This version is much better than the 1st release. Well Done !!
- Improved from last version, I can check the Graphic toolkit and able to see ImageMagick is active...
- I am able to upload image from Local Server. But it does not allow me to upload a folder (unlike Gallery2, it can upload a folder and automatically create an ablum for each folder)
- After upload, there is no rebuilt or thumbnail, just the name of the photo.
- Able to customise the view (theme default). When change the size of the Thumnail, it was prompted immediately that the photos are Out of Date and prompted me to rebuilt, after which I can see the thumbnail and rebuilt. But that does not change the size of the frame on the thumbnail page.
- Changed "Item Per Page" from 9 to 10, getting 3 photos x 3 rows + 1 photo (and 2 space). I suppose this is to be catered by the theme design.
- Changed the size of Resize... does not seems to have any effect, even after the resizes were rebuilt. I think it try to use the new resize (I can see the screen flashed once) ... but then quickly displayed designated 640
- Slideshow (piclensLite) does not seems to work Nor is it customizable. (In Gallery2, PicLens Slideshow was at relative low resolution... I don't like it)
- There is a link "View More Information", click on it will bring up a window with no detail.
- Tried to create an album... I can only move the photos one by one. Preferably multiple select is available. There is also no sorting, when moving the photos to album at random order. They are display at the same random order.
- There is a issue with Album Cover (previously highlights) for multiple level album. Unable to set the Album Cover of levels up.
Can't stop saying again ...this is a good piece of work.
@dennys:
the db schema of g2 and g3 are completely different. we'll have to write an import module anyway, there's no gonna be a simple database transformation to go from g2 to g3.
Regarding using Flash for an essential component
@basilgohar, sremick:
First: relax:
We'll switch from what we have to http://swfupload.org/, which provides the same benefits, and it degrades nicely if Flash is not available. And with swfupload, Flash will be hidden from the user. You can style / theme the upload form the way you want to.
But why Flash, anyway?
Flash provides a number of benefits that aren't available via HTML / JavaScript.
The major reason why we use Flash is the progress bar. We can show you a nice progress-bar while it uploads files. The user doesn't like to wait and giving accurate feedback is key.
With swfupload, we can still do multiple file selection, uploads in the background and show a progress bar. If you don't have Flash, all you lose is the progress bar.
But if not AJAX, why not Java ([insert your favorite technology here])?
- Flash has a crazy market penetration. 99.x% of internet users have Flash installed. Nothing else comes close. Not even Java.
- Flash generally leads to a better user experience than Java. Flash plugins load extremely fast. If one thing annoys users, it's waiting / latency.
- The source code of the Flash components we use is free and open source. The Flash client isn't free (open source), so I understand concerns. But Adobe has gotten better at supporting Linux and 64bit platforms.
(And for people who don't touch any non-free software, there is gnash, the open source Flash runtime / browser plugin.)
Flash has its uses. E.g. it is still the easiest way to serve videos in the browser (without depending on 3rd party players, slow load times, cross-browser issues with embedding videos).
Thanks to faster JavaScript engines, ever improving libraries, and HTML 5, built-in technologies like JavaScript can replace more and more niches where plugins were previously the only option, but we're not quite there yet.
You're kidding. A progress bar? So we lose Java (which works fine for me) and have it replaced with Flash (which Adobe doesn't support on my platform) just for a progress bar?
I'm sorry, but seems a pretty weak reason, especially since a quick Google search reveals numerous methods demonstrating that DHTML/Ajax progress bars are certainly possible and already in-use.
The mere sensibility of requiring a proprietary plugin for a progress bar escapes me and is akin to those websites that require the user to have Flash installed just to have mouseover effects. I would've much-preferred that Gallery continue its previous tendency towards standards, openness, and platform-agnosticism. Justifying shifting from standards-based methods to proprietary ones simply on the basis of "well 99% of our users have Platform X" is a slippery-slope. One could easily use the same justification to make some Gallery features Windows-only.
@sremick:
Whether we use JavaScript, Java or Flash, there will be users that just don't like that technology for reason X.
That's why I started my response with "Relax", explaining that we are changing the upload UI to swfupload, which degrades nicely if Flash is not installed. Again: It will work without Flash.
As for alternatives providing progress-bar without Flash / Java, please show me one that is actually a viable option for Gallery 3. Some of the requirements:
- No dependencies on non-standard php extensions.
- No dependency on Perl or other server side technologies other than apache/php.
- Robust.
- Simple to develop / maintain (that's slightly subjective, let's discuss whatever you find).
Except this also degrades functionality compared to previous versions from people who can't use Flash but can use Java.
I don't understand why Perl isn't allowed, considering Gallery already requires and assumes its presence. Also, on any site the percentage of users uploading is tiny compared to the percentage of users viewing, so if the viewing users are already exercising the Perl engine on the server, any additional load added by uploaders should be minimal.
What's wrong with this?
http://sourceforge.net/projects/uber-uploader/
Demo: http://www.webdice.org/uber_uploader/
This upload form is not replacing Java. There's nothing to stop us from adding Gallery Remote / Gallery Remote Java Web Start to Gallery 3.
This is the standard upload form. It's a big usability improvement over the standard "add item from browser" form you know from G2. Also note that what you see in alpha 2 is not what we have in mind for G3.0. To see what we have in mind, see: http://codex.gallery2.org/Gallery3:Upload_UX
And the UI is all HTML / JavaScript. Flash's used for uploading asynchronously / progress bar (degrades to JavaScript).
@sremick We're not adding a server side dependency on a new language, that would be a massive support headache. We're not adding another Java based plugin, we got reams of negative feedback about that in Gallery 2. We want a progress bar. *Everybody* wants a progress bar. Oh, and everybody also wants the ability to add more than one file at a time (which you can't do with browser forms). Give us a client side, PHP-based, widely acceptable solution that includes progress bars and supports multiple file uploads and I'll strongly consider it. Until then, we're going to go with a solution that has 98%+ penetration (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html).
What platform are you using that *doesn't* have flash? I honestly don't care about "sending a message". I care about making something stone simple that my parents can use to upload photos (and I can tell you that the Java and DHTML based uploaders just don't cut it).
I was under the impression that Gallery used Perl already. I see I was wrong. This makes it easier to grasp some of your comments.
FreeBSD. Runs everything else, including native Java, just dandy. Except that Adobe has decided to not bless it as one of the Chosen platforms allowed to use the "modern" (read: Flash-dependent) web. Yet otherwise I find it as a very capable, versatile, and stable platform (yes, as a GUI desktop)... and it works better than any Linux distro I've used.
But this isn't about FreeBSD or "that one FreeBSD user who makes a fuss." Stepping outside of Gallery for a minute... one doesn't have to look very far to see extremely popular platforms that don't have Flash support, and so are crippled by this trend on the internet to make things Flash-exclusive. The iPhone. The Wii (up to Flash 7 only, so at this point it might as well not have Flash). Most PDAs and cell phones. It just continues to add up that the fewer things that use Flash on the internet, the better... especially when there are alternative methods. Even if they take a bit more coding initially. "Easier" isn't always "better".
I guess I could ask anyone running Gallery: "What webhosting are you using that doesn't have Perl?" ;)
So why not make Gallery Windows-dependent? Probably some nice ActiveX tools even simpler than Flash... ;)
Obviously I've ruffled some feathers here, and I apologize. I just felt a bit betrayed by this new direction of a project I've formed a bit of a relationship with after having used it for so many years. Promoting Flash rubs me the same way as promoting some IE-only control, because it has the same effect on limiting access and promoting proprietary and exclusive technologies. Adobe wants as many sites as possible to promote/require Flash for the same reasons Microsoft did with IE/ActiveX. And if that was the school of thought I connected to, I'd be running an IIS server webserver and using IE7 right now, and would have never cared about Gallery.
@sremick I like view of Gallery3 developers. I was going to pay google for picasaweb to host my whole collection. It was much easier to use than G2. G3 is my wishes come true.
Flash is best way to upload photos for now, sadly it is proprietary. For about 5% users that don't have or don't like flash will be alternatives.
If flash is requiment to upload photo in G3, then I will scream with you
--
Darius Žitkevičius
@cmjimmy: a day late... local import (svn head) now allows you to just check a folder without expanding it and all the children will get added.
http://www.timalmdal.com
Question:
Is Gallery3 still working with WPG2 and wordpress?
If not: Is it hard to make a new plugin which will work with Gallery3 ?
@giel1: re WPG2 and wordpress. Probably not G3 has been rewritten from the ground up. So the existing interfaces will not work.
As for making a module to work with Gallery3... fairly easy from the G3 side. Creating modules is fairly easy. Create a new directory under modules, create a module.info file to describe the module and start filling in functionality. You would probably want to, at a minimum, replace the user module with one that delegates to WPG2 or wordpress user management.
http://www.timalmdal.com
@cmjimmy Thanks for the feedback.
This is a good point and I'll see what can be done.
Good observation. There's a bit of JS in the default theme which ensures that the resize fits in the content area. See themes/default/js/ui.init.js.
I've opened a ticket on this. It should display EXIF information.
--
2tbsp.com
Hi
How about phpbb3 integration?
it is making more sense now... I was using a resize larger than 640. Just tested using 320, it did show the smaller resize.
It sounds like this is another configurable parameter with the Theme design.
Instead, about the parameter "Item Per Page", I would say, is less preferable to "Rows per Page" (as in Gallery2). It added to the burden of the administrator as to what numbers that can fit the thunmnails nicely on one page.
It would be lovely to see Gallery (or in theme design) is smart enough to calculate, from the width of the browser frame and size of thumbnail, to getting the number thumbnails that can be displayed per row. Though, this is only good to have :D
The core team is making no plans to build any integrations. We have designed G3 with integration in mind, so if you or someone else wants to build an phpbb3 integration module, we will be happy to support them.
Tim
http://www.timalmdal.com
"Boolean and full text search (new in alpha 2)"
That one blessed, sweet, sweet line of text.
Thank you. Thank you. Thank you.
fyi: http://t.wits.sg/2008/06/25/howto-php-and-jquery-upload-progress-bar/
-1 for Flash usage
++1 for extensive use of Javascript in the whole interface (it will highlight the speed difference between 1 specific browser and all other browsers which are friendly to web designers ;-) )
@sander1 yes, seen that. It won't work for us; it requires a custom PHP extension that practically nobody has.
@sremick I feel your pain pain of not having Flash on your desktop (although 5 seconds of using Google turned up http://www.google.com/search?hl=en&q=flash+on+freebsd+firefox&btnG=Search which shows that there are ways to do it). But you've chosen to use a minority setup and as such you have to accept that your choice will come with some limitations. We're not going to go out of our way to support edge cases like this.
I still have not seen a compelling reason not to use Flash for this highly targetted purpose. To reiterate, I am not interested at all in ideological reasons, I am only interested in the simplest most practical way to get certain required functionality. Web design friendliness arguments hold no water here since this is clearly a tool with a very narrow scope that's only going to get used by a tiny subset of the people who view Gallery installs. Until somebody gives me a compelling reason why using a Flash uploader is bad for our end users, I will strongly argue that we continue going in the direction of what's simplest for our end users.
As a user of Gallery, it really does not make real impact to me whether this is Flash or Javascript (except the Slideshow in Gallery 2.3
which the flash version has an unacceptably low resolution for use with somewhat Hi-Rec Photography, the tool is not matching to the intended purpose).
For Admin purpose, I can't see why the team should choose to write (and debug) tonnes of codes with Javascript instead of Flash which is proven to work quite well.
Please don't... force us (it meant every single Gallery3 installation) to install whatever CUSTOM PHP extension ... that it is working fine now without it. I don't believe this is the right approach. I don't understand why not Flash that simply work as always to a custom PHP extension.
@cewan: Yes local_import is a wee bit shaky, but i'm still working on it
Update: svn head now has a much more robust local_import module. I just import over 400 images in one go, including building the album tree structure that mirrored the file structure of the source directory.
http://www.timalmdal.com
Thanks, I know g3 is completely write. Is it possible to keep a mapping when import from G2? I think if I have the id mapping (whatever the format, database table or just a plain text), I can use some tool or write a small program to change my other software.
For example, I'm using Drupal to embed some G2 and it uses "[G2:123]" to show id 123 image. If G2's 123 image will become id 456 in G3, I need to change "[G2:123]" in Drupal to "[G3:456]" (If there is a new module to integrate G3 and Drupal)
Here's a thought:
You talk of how lack of Flash support on the viewer's desktop allows for elegant fallback to a non-flash solution that simply lacks the features that having Flash provides. You frame this as an acceptable compromise for those who do not have Flash or do not want to use Flash. You mention that this makes sense since most people have Flash installed on their desktops.
On the other hand, you talk about not wanting to have any more "requirements" (such as Perl) on the back-end. Despite the fact that most people have Perl installed on their webservers/webhosts.
How about this... don't "require" Perl, but have the backend "degrade nicely" if Perl is not present. This would allow the webmaster to decide what level of experience he's willing to provide to the users of his/her website, and not have it be dependent on the capabilities/OS of the viewer's client.
As a webmaster, I'd much-prefer to make the choice on the back-end and enable Perl to allow the full feature set to be available to all users. But you can let it degrade nicely to a non-Perl no-progress-bar option for those edge cases who don't have Perl on their server.
@sremick:
Or, you can just write your own upload plug-in that uses what ever you like. You could even share it with other like minded individuals.
As Bharat, has repeated on numerous occasions, we are not trying to write another "multi-sized; address 100% of the requirements" online web gallery. Our target is to have the delivered product, meet the requirement of 80% of our users. And we are looking to the gallery community to build and maintain the other 20%.
In my opinion, your concern about flash falls into the 20%, so the team will probably not address something like this due to other priorities.
Tim
http://www.timalmdal.com
sremick: I agree with your point of view. I have a very good hosting service (not expensive) on which I am not limited to only a few libraries and tools.
Gallery Team: please at least add an option (may be a config-file-only option) so that webmasters can disabled the use of Flash.
Another argument against the use of Flash: as a user I have Flash installed because I want to watch videos on Youtube when someone sends me a link. So, I need to have Flash installed. However, I don't want Flash for goodies like progress bars *because* it drains battery power (at least CPU usage of Flash compared to JavaScript is much higher on Mac OS X and Linux). End users want to be able to watch Youtube videos using their laptops and smartphones; using Flash for goodies is just a waste of battery power.
@sander1 / @sremick: Again, I need to stress that we are building a tool for the masses not for the corner cases. Gallery 2 provided an overabundance of options that most users did not need which generally just confused our users and hurt us. Not only do we have to support these configurations, but we don't use them ourselves so they don't get much testing and they slow down our release process. If 80% of our users don't want the feature then we are not going to write it. Please follow talmdal's advice and write your own module to do it any way that you wish. Writing modules is *easy*. You can make Gallery 3 sing and dance to whatever tune you prefer.
@sander1 The battery power argument is interesting, but I'm very dubious. If you can show me some benchmark numbers to back this up I'll definitely consider it. Though realistically, I doubt that this is a significant concern for 80% of our users since it's only for photo uploading.
@dennys yes, I think it's a requirement that we provide a mapping from G2 ids to G3 ids during the import process. This would allow us (for example) to provide a mod_rewrite mapping that fixes up urls, too. We'll do something along these lines, just not sure what yet
I just finished checking out the latest svn release and I've been very impressed so far. Installation is dead simple and it seems to be a lot more responsive than its predecessor.
Also i know its a work in progress, but at the moment the photo uploader only accepts files with lowercase extensions (not a major problem but something that i can't fix myself
).
The combination of Windows and XAMPP 1.7.0 still not working... Fatal error: Cannot access empty property in D:\web\gallery-3.0\kohana\libraries\drivers\Database\Mysqli.php on line 122
I have noticed that Windows support is not a priority. But it must be allowed to hope that one day Gallery 3 also will run at the mentioned WAMP platform....
bharat: documenting something like this is sufficient for me and it will only slow down the release process with a few secs:
flash_progress_bar_function {
# comment the below lines do disable Flash shit <-- (1) this needs to be added
show_flash_code
}
(2) add this to the docs (e.g. README): To disable Flash, comment the code in flash_progress_bar_function in the file src/file.php
Looking good. Just my two cent on the comments so far:
- Yes to flash over java. Having done a number of reinstalls in the last 18 months, one of the first things I went to download after the installation was done was flash. Not a single machine ran java - and not a single user has complained. This includes my own development machine and servers. I understand how programmers may be more comfortable with java, however from an end-user point-of-view flash is the sounder option. Plus flash has come a long way in the last two years (rather than just being a show-off point-less feature of over designed sites).
- Lots of broken things still, but there's no point listing them as I have no doubt they'll get sorted at the right time.
bharat: btw, a similar way to disable *all* Internet Explorer hacks (W3C strict mode) would be very welcome as only 20% of my visitors uses this buggy browser (and only 30-40% of them do use IE6)...the more websites that will render bad in non-strict browsers, the bigger the pressure on Microsoft to adopt open standards (I want to contribute to this with me website ;-) )
After a 5 minute install from my netbook, lol and a few minutes of adding images, I am liking the Alpha2 version much better than the Alpha1.
I'll post again after more thourough testing, but here it is: http://www.beeerlover.org/gallery-3.0-alpha-2/index.php/
Thankx Again!
After a bit more time with it, I notice the translation feature does not work as quite like expected, but no biggie here.
The import from local server & add photos (locally) features now seem to work flawlessly after an initial problem with there not being an 'albums' folder inside of '../gallery-3.0-alpha-2/var/'. Once I manaually created this folder (perhaps just a problem on my server/config) it works like a champ even on my old server.
I have Imported hundreds of Pink Floyd pictures from my G2 install at http://www.beeerlover.org/ into G3 Alpha2 at http://www.beeerlover.org/gallery-3.0-alpha-2/index.php/
Thank again!! Gallery rocks!
It would be good to add search by IPTC (keywords)
This new version of Gallery is simply awesome! Although it would be nice to have to tool tips on some of the icons in Gallery, like on the side. Some tool tips explaining the permissions would also be useful, like when it says 'deny', is it currently denying access, or do you need to click it to deny access.
sremick: Any chance you can stop with the pointless Flash bickering now? You've made your point, the uploader will work fine anyway.
Over 99.5% of people have flash, I suspect 99% of people want the progress bar, and <0.001% of people care that you choose to use Freebsd as a desktop client, which also represents a tiny minority. And isn't gnash available as an alternative on your platform?
Tell you what - there are still a few thousand people who have black and white TVs in the UK - are you suggesting the broadcasters stop broadcasting programmes in colour and go back to designing sets and programmes in greyscale-friendly colours (as they used to) to suit those few?
There's a 101 things we could do to help suggest improvements and fixes - bickering about a tiny tiny minority isn't helping. It's this kind of bickering over standards that ended up with wikipedia's recorded articles being ogg-only, and everyone loses out. You not only want things your own strange way, you want everyone else to suffer too.
I haven't posted in 9 days. Why are you bringing it up again?
I'm excited for the new G3 release. I was thinking of installing G2 for a commercial site I have. Will it be more of a hassle if I setup G2 and transition to G3, considering G3 is coming out soon? In about how long would you expect to have G3 out?
Gallery 3 is going to take us a while. We've got a lot of tickets left to close! http://apps.sourceforge.net/trac/gallery/query?status=assigned&status=new&status=accepted&status=reopened&group=status&milestone=3.0+Alpha+3 is our latest list. We're not going to do all those things, but there's a lot to do and only 4 people who are really heads down on the development. If you can find more devs for us, it'll make things go faster
Good day.
I want to create gallery in which all will be about 1000 albums (100 albums, in each of which is 10 sub-albums) and all will be about 50000 photos.
Taking into account the above-stated parameters of gallery, answer, please, two questions:
1) As far as is faster (approximately in %) the Gallery3 will work in comparison with Gallery2.3 on a virtual hosting?
2) As far as is less (approximately in %) the Gallery3 will load a server of hoster in comparison with Gallery2.3?
Beforehand thanks for answers!
Giving benchmarks in percentage is virtually impossible. I have done some benchmarking on one of my shared hosts and with each pass got different numbers.
I can only guess that some people will do some testing and come to different concussions.
What test(s) should we perform to come up with these numbers?
Perhaps starting a thread in the forums with your results will spur others to add their data.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team