From: Bharat M. <bh...@me...> - 2013-01-14 20:43:49
|
On Mon, Jan 14, 2013 at 11:57 AM, Mike Miller <ga...@mi...> wrote: > On Mon, Jan 14, 2013 at 9:27 PM, Bharat Mediratta <bh...@me...> > wrote: > > > > Welcome back, Mike :-) > > > > I suspect that there are several better ways to do this, but it sounds > like > > what you have now works so we should start by getting it into the > > gallery3-contrib repo. Can you fork gallery3-contrib on github and move > > your module into the 3.0/modules directory and submit a pull request? > > That'll get it into a central location where we can hack on it together. > > I'm going to suggest some stuff below, but don't worry about doing those > > things yet - just start by getting into share source control first. > > General git question: I have my own repository at > https://github.com/mikeage/panorama (which I added to my local > gallery3 directory as a submodule). Is there any easy way for me to > share this with my gallery3-contrib fork while also keeping it as it's > own repository? > > [OT: in general, I'm not sure I understand the idea behind one repo > containing all the semi-official modules; doesn't this make it rather > difficult for contributors to maintain their own module? There's quite > a lot of development that goes on via forum uploads... would > submodules encourage people to keep their code in some form of formal > source control?] > Short answer is - I don't know. The common model I see most folks do is that they fork gallery3-contrib and do their dev in their own fork and push stuff back upstream. You wind up with a bunch of extra code but that's useful in its own way because you have a lot of code samples handy. From our perspective it's great because it gives us an easy way to find and fix issues across a wide range of contrib modules without a lot of hassle. You can probably do some git magic to keep the two in sync, but my git fu is not good enough to tell you offhand. Or you can just copy stuff over and submit pull requests every once in a while. > > > Next up, I like the resize_img hack, but it's a hack because we want to > > avoid having to override Item_Model. You can only ever do one override > so > > your module will eventually clash with other ones. I think a better > model > > is to do what we do with Item_Model::movie_img where we load up all the > data > > to build the tag and then call out to the movie_img event and let any > > modules return a custom view. In your case you'd modify > > Item_Model::resize_img to mimic the same event driven model and submit a > > pull request to the gallery3 repo, then in your module you'd create an > event > > handler which receives the resize_img event and returns your your > <object> > > tag in your own custom view. > > I _think_ I understood that, at least in general, though I'll need to > re-read it a few times to make sure. Another option I considered > before I tried this approach was to rewrite the tag using JavaScript > (or is that what you were proposing by a custom view?) > Rewriting it with JS is clunky because it means that we know we're generating the wrong thing first. Take a look at the code for movie_img - it should be clear enough. > > > Gallery3 only supports a single resize - multiple resizes were too > confusing > > and didn't provide a lot of benefit. Do you really need to have multiple > > resizes for this to work smoothly? > > At the moment, yes. Flash seems to be limited to a 16 megapixel image > (for the 360x180 surface the panorama is stored on; if the user > uploads a partial panorama, like most of mine are, the actual resize > must be smaller). Moving to HTML5 (or back to Java, like the original > G2 viewer used) might offer some advantages there; I need to look > what's out there that's (a) free and (b) supports (or can be easily > adapted to support; I didn't write the viewer I use, but I did hack it > a bit) partial panoramas. > > In G2, I also used multiple resizes as a way to let the user see any > combination of the following (though this requirement is much less > important IMHO): > * Thumbnail > * Normal resize (regular view) > * Panorama view using a special resize > * Full size (regular view) > Unfortunately I don't understand the panorama constraints well enough here to provide informed guidance. Let's do this incrementally - get it working and in decent enough shape that I can pull it in and play with it and then hopefully I'll have time to learn enough about it to push on it. > > > Also, do you have a demo up somewhere? > > http://mikeage.net/testing/gallery3/Panorama-Tests has a few images, > including one that's too big. Note that many of these are deliberately > _not_ cropped for testing purposes, which is why all, except for "Test > 155x56" and "Test Full" will often have patches of black background > visible. That's not a bug. > Cool! > > -- Mike > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > __[ g a l l e r y - d e v e l ]_________________________ > > [ list info/archive --> http://gallery.sf.net/lists.php ] > [ gallery info/FAQ/download --> http://gallery.sf.net ] > > |