Menu
▾
▴
ids-devel — IDS developers use this list
You can subscribe to this list here.
| 2001 |
Jan
(2) |
Feb
(48) |
Mar
(16) |
Apr
(14) |
May
(42) |
Jun
(36) |
Jul
(57) |
Aug
(13) |
Sep
(2) |
Oct
(23) |
Nov
(17) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(12) |
Oct
(26) |
Nov
(11) |
Dec
(37) |
| 2003 |
Jan
(11) |
Feb
(27) |
Mar
(5) |
Apr
(21) |
May
(11) |
Jun
(38) |
Jul
(8) |
Aug
(29) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(5) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(19) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
|
From: nicole <tha...@fr...> - 2001-12-10 00:03:22
|
this is a stupid question really.. but when linking to .htpasswd from .htaccess what is the form supposed to be? relative or absolute? i cant get it to accept my password when i hit the first page (/admin) |
|
From: Randy M. <ra...@ac...> - 2001-11-24 17:09:40
|
Hello, I've been hacking on my increasingly out-of-date variation of IDS. I'll call it v0.7-rcm Its a close a cousin of 0.7 something. I don't run CGI's on a public web server or Apache at all, so IDS runs on one machine and builds a static version of the web page. I'm sure that can be useful to someone else. It probably has a number of quirks or bugs, but it works ok for me. Since 1.0 is a total rewrite, there seems to be little point in updating portions to 0.81 and sending patches. Or is there? Maybe I'm not the only one who won't be using the 1.0 line... I've rearranged portions of the code (for various reasons) that make a simple diff tricky. I usually have three versions: ie, I might download 0.8, and make a 0.8-hack version that gets rearranged, diffed, poked, etc so my 0.7-rcm version can be updated. It doesn't gain everything that a mainstream version has to offer, but most things. From there I'd dump 0.8-hack and do it again. This time 0.8-p1 would be updated with some fixes from 0.7-rcm and fixes to make it work right on its own. At somepoint I'd send a patch or two to John or the list, and continue on. Eventually I'd like to think that 0.8-p3 (or so) and 0.7-rcm would be really close and update 0.7-rcm with some more fixes. Atleast I'd understand some of the code changes in the main version. Needless to say thats a lot of work. But I don't see how else to do it. The code is changed for various reasons -- the rearranged code for example is usually because I moved a redundant or useful subroutine from one of the .cgi files to the shared module. And the HTML templates that are standard were simply not enough for what I was doing once upon a moon. I sent a recent tarball to John; I don't mind if its a dead line. So the crux is this: Should I evolve it up to 0.8? I also don't mind if 0.8 isn't a dead line; I don't have much time to contribute useful things to 0.8 or others. All the best Randy Maas |
|
From: Phillip T. <ne...@ya...> - 2001-11-23 01:14:17
|
I have a webserver with more disk space than cpu (p75,
24 mb RAM, 13 gigs... yeah I know), so I added the
following two lines to previewmaker.pl to pregenerate
all the resized images in the image-cache:
in this section:
---------note the lines with a + ------------
print "Beginning preview generation...\n";
foreach $file (@FilesToPreview) {
createDisplayImage($previewMaxDimension, '',
$file);
+ createDisplayImage($maxDimension, '', $file);
+ createDisplayImage(512, '', $file);
print "Created preview for \"$file\"\n";
}
---------------------------------------------
I'm not sure if this is the "right" way to do this,
but it seems to work, and my poor webserver seems much
more responsive. I guess this could be added as a
command line option.
__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
|
|
From: Jeff D. <je...@ba...> - 2001-11-21 02:43:35
|
> A little grovelling around apache.org/docs and I got > it running. My initial config, however, led to being > able to access ids.conf and other files if you knew > they existed: (i.e. > http://photos.tiburcio.info/ids.conf or /LICENSE, > etc). I consider this kind of a design flaw with IDS. The placement of CGIs, config files, and static content in the various directories makes it somewhat challenging to secure the installation. The secure method would be to utilize a scriptalias but this doesn't work because directories underneath IDS contain static content. This is where the primary problem is. The problem is the structure should be something like: ids/cgi ids/conf ids/data with all CGIs and modules going in the CGI directory, config data going in the conf directory, and data (static content) going in the data directory. Then a serveralias can be pointed into cgi and web access to conf can be denied. With the current directory structure, static content is served from underneath the directory in which the CGIs reside. This type of directory structuring for a CGI is typically considered to be flawed due to the relative difficulty required to secure an installation. I use the convolution below to attempt to mitigate this issue: <VirtualHost 216.10.47.13> DocumentRoot /var/www/personal.subcultural.com ServerName personal.subcultural.com ErrorLog /var/log/apache/personal.subcultural.com-error.log CustomLog /var/log/apache/personal.subcultural.com-access.log combined <Directory /var/www/personal.subcultural.com/ids/> SetHandler cgi-script Options ExecCGI AllowOverride AuthConfig </Directory> <Directory /var/www/personal.subcultural.com/ids/image-cache/> SetHandler default-handler Order Deny,Allow AllowOverride None Options None Allow from all </Directory> <Directory /var/www/personal.subcultural.com/ids/themes/> SetHandler default-handler Order Deny,Allow AllowOverride None Options None Allow from all </Directory> <Directory /var/www/personal.subcultural.com/ids/albums/> SetHandler default-handler Order Deny,Allow AllowOverride None Options None Allow from all </Directory> <Directory /var/www/personal.subcultural.com/ids/album-data/> SetHandler default-handler Order Deny,Allow AllowOverride None Options None Allow from all </Directory> <Directory /var/www/personal.subcultural.com/ids/site-images/> SetHandler default-handler Order Deny,Allow AllowOverride None Options None Allow from all </Directory> User personal Group personal ## push personal.subcultural.com directly into IDS RewriteEngine on RewriteRule ^/$ /ids/ [R] </VirtualHost> This configuration essentially defines /ids (and everything under it) as being a CGI directory, in which content can only be executed and not retrieved, and then goes down the tree under that defining the directories are OK for content to be retrieved from. This should not be necessary, the static content should be moved out from under the cgi part of the directory structure. Jeff |
|
From: Phillip T. <ne...@ya...> - 2001-11-20 06:18:45
|
Thanks for the tips everyone! I've decided to go with the excellent suggestion of a vhost: http://photos.tiburcio.info/ -> ids/ A little grovelling around apache.org/docs and I got it running. My initial config, however, led to being able to access ids.conf and other files if you knew they existed: (i.e. http://photos.tiburcio.info/ids.conf or /LICENSE, etc). This sort of made me nervous, so I added the following to my vhost section to try and get to a more secure state: # deny attempts to directly read any IDS configuration # or maintenance/incidental files <FilesMatch "\.(pl|conf|txt|pm|stackdump)$"> order deny,allow deny from all </FilesMatch> # Some ids files are all caps, # README,CREDITS,LICENSE, etc. Deny those too <FilesMatch "[A-Z][A-Z]+"> order deny,allow deny from all </FilesMatch> # allow all .cgi, graphics and html files <FilesMatch "\.(cgi|jpg|gif|jpeg|png|html)$"> Order deny,allow allow from all </FilesMatch> It's kind of kludgey but it seems gets the job done. Hope somebody finds it useful, or can show me a better way. Thanks again! __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 |
|
From: Jeff D. <je...@ba...> - 2001-11-18 23:50:07
|
----- Original Message ----- From: "Phillip Tiburcio" <ne...@ya...> To: <ids...@li...> Sent: Saturday, November 17, 2001 1:39 PM Subject: [Ids-devel] alternate path question > hello everyone! I have a question regarding path > configuration, but first I'd like to thank the > developers for providing such an excellent photo album > system. This is a very sharp project and everyone who > has seen my ids pages loves it. keep up the good work! > > The question I have is this: currently the way to get > to my ids site is to hit > http://servername.org/cgi-bin/ids/index.cgi. > (I am running ids 0.8/apach 1.3.22/perl 5.6.1 under > windows 2000+cygwin) If you have mod_rewrite enabled, you could do something like this: RewriteEngine on RewriteRule ^/$ /cgi-bin/ids/ [R] Jeff |
|
From: Ashley M. K. <as...@pc...> - 2001-11-17 19:13:36
|
Phillip Tiburcio wrote: > The question I have is this: currently the way to get > to my ids site is to hit > http://servername.org/cgi-bin/ids/index.cgi. > > I tried to simplify the path by using a scriptalias > command in httpd.conf: > > ScriptAlias /album/ > "/usr/local/www/cgi-bin/ids/index.cgi" > > I read through the faqs/documentation but I couldn't > find how to properly create an URL alias. What is the > proper way to accomplish this? None of the images show up because it's taking the last bit, 'index.cgi' and tacks everything else on it, so at some point, your internal paths become /usr/local/www/cgi-bin/ids/index.cgi/index.cgi?mode=...etc. - Try removing the 'index.cgi' from it. -- IDS can be placed just about anywhere really. What you need to do is allow CGI scripts to run from where ever you install it. For example, instead of putting it in your /cgi-bin/ folder, drop it outside, and put it in a folder under your /htdocs/ directory. Say, make a new one called album under /htdocs/, and drop IDS in there. Your physical path would then be /usr/local/www/htdocs/album/ and you should be able to hit http://your.host/album/ (you have to delete your script alias you added, and you need to allow ExecCGI in the /album/ folder - read the Apache docs for that) In my case, I have IDS running completely outside of my main Apache folder. It's a vhost all by itself. http://photos.yeehaw.net translates to /home2/apache/photos.yeehaw.net/htdocs/ while Apache itself is under /usr/local/apache/ (besides, with my IDS being so large, I had to move it onto another drive all together) -- H | "Life is the art of drawing without an eraser." - John Gardner +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 Director of Internet Operations / SysAdmin . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: Phillip T. <ne...@ya...> - 2001-11-17 18:39:31
|
hello everyone! I have a question regarding path configuration, but first I'd like to thank the developers for providing such an excellent photo album system. This is a very sharp project and everyone who has seen my ids pages loves it. keep up the good work! The question I have is this: currently the way to get to my ids site is to hit http://servername.org/cgi-bin/ids/index.cgi. (I am running ids 0.8/apach 1.3.22/perl 5.6.1 under windows 2000+cygwin) I tried to simplify the path by using a scriptalias command in httpd.conf: ScriptAlias /album/ "/usr/local/www/cgi-bin/ids/index.cgi" (this line may have wrapped itself in this email) This sort of works: hitting http://servername/album/ results in the text top page being displayed, but no images at all. I read through the faqs/documentation but I couldn't find how to properly create an URL alias. What is the proper way to accomplish this? Thanks! __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com |
|
From: asja <as...@se...> - 2001-11-13 00:28:04
|
On Sun, Nov 11, 2001 at 03:39:28PM -0700, Ashley M. Kirchner wrote: [...] > << -10 | 6 | 7 | 8 | 9 | 10 | +10 >> (or something like that) > ...click next: > << -10 | 11 | 12 | 13 | 14 | 15 | +10 >> > ...click +10: > << -10 | 21 | 22 | 23 | 24 | 25 | +10 >> This is the approach I personally prefer. I am using 12 thumbnails for each page, and using this method, just 10 clicks are sufficient to jump ahead 1200 images... and the page looks very good. This approach is often used by huge image gallery sites, such as Webshots. Even if it's not as powerful as a text input box, it's much easier to understand for common users and looks nice. Regards .asja |
|
From: Ashley M. K. <as...@pc...> - 2001-11-12 21:40:39
|
John Moose wrote: > How's this? > http://miranda.hn.org:8888/pagekit/album?location=This%20is%20%22fun%22/Really%20Big%20Album > > I like this approach because it gives you all the flexibility of listing > every page, but takes up very little screen real estate. It also include > "previous" and "next" links so as not to overwhelm the casual user. Yeah, that works for me...since I don't have a lot of images per category. asja on the other hand does, and 87 pages on a drop down is a bit too much I think. Then again, I don't know how to please everyone, so...we'll just have to see. Another idea I had was similar to the drop down, but instead of a drop down, just put an input field and display the current page in it. Then the user can type in whatever page they want to go to. One problem noted: go to the last page, you lose the drop down. -- W | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: John M. <mo...@mu...> - 2001-11-12 21:30:43
|
How's this? http://miranda.hn.org:8888/pagekit/album?location=This%20is%20%22fun%22/Really%20Big%20Album I like this approach because it gives you all the flexibility of listing every page, but takes up very little screen real estate. It also include "previous" and "next" links so as not to overwhelm the casual user. John On Sunday, November 11, 2001, at 05:39 PM, Ashley M. Kirchner wrote: > John Moose wrote: > >> Thanks for all the ideas. I'm still thinking about most of them, but >> how's this for #2? >> >> http://miranda.hn.org:8888/album?location=This%20is%20%22fun%22/Woods%202000%2d08%2d20 >> >> Previous/next links are much easier to code! > > The only problem I see with this is that you can't jump ahead in > pages. On asja's > page ( > http://earth-sky-water-fire.org/cgi- > bin/ids/index.cgi?mode=album&album=/water/reefs%2cfishes%2csea%20life/small > ) you can see there are 87 pages, and if someone visited the first 23, > then left and came > back, they can jump right in and click on page 24 and continue > browsing. That was the > advantage really of having all the pages listed like that, however it's > not the most ideal > way. > > On your sample John, there's no way to jump from one page to some > other, except for > going to the next, next, next, next, till you get where you're going. > This goes the same > for the idea I proposed, however at least one could jump ahead five > pages at a time (if > implemented): > > << 6 | 7 | 8 | 9 | 10 >> > ...click next and you get: > << 11 | 12 | 13 | 14 | 15 >> > > But again, if I took asja's page as an example, one has to click a > few times to get to > where they're going. So I thought maybe amend what I originally posted: > > << -10 | 6 | 7 | 8 | 9 | 10 | +10 >> (or something like that) > ...click next: > << -10 | 11 | 12 | 13 | 14 | 15 | +10 >> > ...click +10: > << -10 | 21 | 22 | 23 | 24 | 25 | +10 >> > > One could also just do a single < > for next, and double << >> for > ahead +/- 10 pages > in which case I would suggest flipping the links: > << < 11 | 12 | 13 | 14 | 15 > >> > (watch, someone is going to say, 'but we need a link to go back to > page 1', heh) > > Mind you, from a programming stand point this isn't exactly a piece > of cake (I've > tried it before in a different language), but once working, it's rather > sweet. (And I > only suggested +/- 10, doesn't mean we have to adhere to it, nor the > display of 5 page > numbers in a row) > > -- > H | "Life is the art of drawing without an eraser." - John Gardner > +-------------------------------------------------------------------- > Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 > Director of Internet Operations / SysAdmin . 800.441.3873 x130 > Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6 > http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. > > |
|
From: Ashley M. K. <as...@pc...> - 2001-11-12 00:33:49
|
After doing some thinking, I thought of another way of displaying
those page links. Keep in mind that I'm basically going after sites
that have some large number of pictures, which in turn generate a large
number of page links. This won't have any effect on people with small
numbers of links.
gaps = Npages / 15 (slots) -5
I say -5 because I want to add, my current page, plus two under, and
two over in the resulting list.
What will this do? Let's say I have a section that's generating 154
pages, and I'm currently viewing page # 53:
154 / 15-5 -> 15 (we'll round down), so now my "gaps" will be:
1, 16, 31, 46, 61, 74, etc.
We insert page 53 where it should be in the list, plus two down, and
two up from there, and we add the first, and last page also. The
result:
1, 16, 31, 46, 51, 52, 53, 54, 55, 61, 76, 91, 106, 121, 136, 151, 154
You want to know how my screwed up mind came up with this? Let's
assume you have in your hand, some very very fine calibrated ruler, with
the little lines marking every inch, half inch, quarter inch, 1/8, 1/16,
1/32, 1/64, etc., etc. on it, but the smaller the scale, the smaller the
letters. Now I'm going to give you a magnifying glass to look through.
What do you see? What's right in the middle you can see just fine, down
to the very fine print, but as you look to the side, you can't see the
same (small) scale anymore, just the one above that, or a few scales
above that. It's kind of like looking through a water bubble sitting on
a page of a book.
Think of the above links the same way. As you near your current
page, the numbers are more granulated, but as you move away, the "gaps"
become bigger.
Sick thinking, huh? :)
--
H | "Life is the art of drawing without an eraser." - John Gardner
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
Director of Internet Operations / SysAdmin . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Ashley M. K. <as...@pc...> - 2001-11-11 22:39:38
|
John Moose wrote: > Thanks for all the ideas. I'm still thinking about most of them, but > how's this for #2? > > http://miranda.hn.org:8888/album?location=This%20is%20%22fun%22/Woods%202000%2d08%2d20 > > Previous/next links are much easier to code! The only problem I see with this is that you can't jump ahead in pages. On asja's page ( http://earth-sky-water-fire.org/cgi-bin/ids/index.cgi?mode=album&album=/water/reefs%2cfishes%2csea%20life/small ) you can see there are 87 pages, and if someone visited the first 23, then left and came back, they can jump right in and click on page 24 and continue browsing. That was the advantage really of having all the pages listed like that, however it's not the most ideal way. On your sample John, there's no way to jump from one page to some other, except for going to the next, next, next, next, till you get where you're going. This goes the same for the idea I proposed, however at least one could jump ahead five pages at a time (if implemented): << 6 | 7 | 8 | 9 | 10 >> ...click next and you get: << 11 | 12 | 13 | 14 | 15 >> But again, if I took asja's page as an example, one has to click a few times to get to where they're going. So I thought maybe amend what I originally posted: << -10 | 6 | 7 | 8 | 9 | 10 | +10 >> (or something like that) ...click next: << -10 | 11 | 12 | 13 | 14 | 15 | +10 >> ...click +10: << -10 | 21 | 22 | 23 | 24 | 25 | +10 >> One could also just do a single < > for next, and double << >> for ahead +/- 10 pages in which case I would suggest flipping the links: << < 11 | 12 | 13 | 14 | 15 > >> (watch, someone is going to say, 'but we need a link to go back to page 1', heh) Mind you, from a programming stand point this isn't exactly a piece of cake (I've tried it before in a different language), but once working, it's rather sweet. (And I only suggested +/- 10, doesn't mean we have to adhere to it, nor the display of 5 page numbers in a row) -- H | "Life is the art of drawing without an eraser." - John Gardner +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 Director of Internet Operations / SysAdmin . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: John M. <mo...@mu...> - 2001-11-11 21:42:06
|
Thanks for all the ideas. I'm still thinking about most of them, but how's this for #2? http://miranda.hn.org:8888/album?location=This%20is%20%22fun%22/Woods%202000%2d08%2d20 Previous/next links are much easier to code! John On Friday, November 9, 2001, at 05:40 PM, asja wrote: > Hallo, > I am currently using IDS 0.81 successfully, i find it very stable and > mature, yet i would like to tell you some of my wishes and observations: > > 1- First, maybe the only "bug" in IDS: if there is any problem accessing > an image (corrupt file, bad permissions, other troubles), let's > say, a .jpg file, in an album, IDS fails showing me even the album > thumbnails, and bails infamous errors like: > "Software error: > Warning 330: Unable to open file (...) > [Permission denied] at /idsShared.pm line 611." > > It would be better if IDS let me see the album and just warn me about > the damaged file when i try to access it (or mail the admin, or > whatever > you find useful but not alerting users this way!). > > 2- In the album's thumbnails view, i think it is important to have a > "NEXT" and a "PREVIOUS" page link, just because i am currently > running > directories with THOUSANDS photos (over 16000 photos in the entire > gallery) and the album's page looks awful > ie: http://earth-sky-water-fire.org/cgi- > bin/ids/index.cgi?mode=album&album=/water/reefs%2cfishes%2csea%20life/small > Users often get lost browsing those albums, and if i don't use very > evident > link colors it's very annoying figuring out which page is actually > shown. > Even worse: the page # links are not properly formatted, sometime > they > look very messy, unless you use monospaced fonts (ugly!!) what about > tables? > > 3- I would love to customize the link of "main page" shown in each IDS > generated page, as i have a quite complex homepage and i would not > transform it into an IDS template (it also uses SSI and other CGIs..) > > 4- I would like to add a downloader helper to IDS, which takes the > images > from the server filesystem and gives them to users, without allowing > direct downloading. This should be useful to implement other > features, > like access counters, download restrictions based for example on file > size or system time (i did it with an humble workaround, but it > works) > and also anti-mirroring triggers and alerts. > Well i know two things about this: first of all, it could affect > performances, so it should be enabled only on sysadmin's demand, and > then that all of these features could be implemented in other ways > (apache directives, tiny patches, general purpose wrappers and so). > However i find that having this feature built into IDS would be nice. > > 5- Sometime ago i saw a "static version" of ids floating around (maybe > on > your website) which was not supported by you. I suspect it worked > "rendering" each webpage in the gallery and storing it on the disk > into > a static tree. I would love to have a look at it, because i could > need > to put up a mirror site for my collection on a CGI-less webserver. > It could improve performances too, losing a bit of flexibility. > > Besides those little details, your program is great. Just one of the > most > powerful-yet-simple tools i've found around, and i am very happy with > it. > > I am not a perl programmer, but as always i'll test your software on my > quite big gallery, and can help you coding C helpers, if you wish. > > Best regards > .asja > > -- > as...@se... > http://earth-sky-water-fire.org > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > https://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Ashley M. K. <as...@pc...> - 2001-11-10 00:49:05
|
asja wrote: > 2- In the album's thumbnails view, i think it is important to have a > "NEXT" and a "PREVIOUS" page link, just because i am currently running > directories with THOUSANDS photos (over 16000 photos in the entire > gallery) and the album's page looks awful > ie: http://earth-sky-water-fire.org/cgi-bin/ids/index.cgi?mode=album&album=/water/reefs%2cfishes%2csea%20life/small > Users often get lost browsing those albums, and if i don't use very evident > link colors it's very annoying figuring out which page is actually shown. > Even worse: the page # links are not properly formatted, sometime they > look very messy, unless you use monospaced fonts (ugly!!) what about tables? Tables or not, it wouldn't make much of a difference. You'd still end up with a very long list of links. However, your idea of 'next' & 'previous' might be one solution...or even slightly different: Say you're on page 35, you'll see links like this: << 33 34 35 36 37 >> In other words, put two additional pages, left and right of the current one you're viewing, and add << and >> for the next set of 5 pages. As for your comment on them not being properly formatted, yes that's true. It's being listed as 'page xx' every time, which in your case you can see gets to be rather long and unpleasant. I don't have any of my sections that contain that that many pictures in it, mainly because I categorize everything by rolls of film. The most I have in one section is 46 images (4 pages on a 4 x 3 grid). However, even then I did change my IDS settings: - in my language setting files, I changed 'album-pageNumber' to just say "%pageNumber" as opposed to 'page %pageNumber' - cuts down on the amount of text. - In index.cgi itself, I changed the linksToPages section to give the active page a different CSS class. By default, all those links are 'album-pagelinks'. By adding another class, 'b-album-pagelinks' and hacking the linksToPages section, I can now have the active page have a different number. Makes it easy to see where you're at. You can see the result here: http://photos.yeehaw.net -> Vacations -> Colorado, 2000 -> Pikes Peak > 3- I would love to customize the link of "main page" shown in each IDS > generated page, as i have a quite complex homepage and i would not > transform it into an IDS template (it also uses SSI and other CGIs..) Unfortunately, those links are hardcoded into the system. > 4- I would like to add a downloader helper to IDS, which takes the images > from the server filesystem and gives them to users, without allowing > direct downloading. You're better off using a third party software for this. Or write your own. -- H | "Life is the art of drawing without an eraser." - John Gardner +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 Director of Internet Operations / SysAdmin . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: asja <as...@se...> - 2001-11-09 22:40:49
|
Hallo, I am currently using IDS 0.81 successfully, i find it very stable and mature, yet i would like to tell you some of my wishes and observations: 1- First, maybe the only "bug" in IDS: if there is any problem accessing an image (corrupt file, bad permissions, other troubles), let's say, a .jpg file, in an album, IDS fails showing me even the album thumbnails, and bails infamous errors like: "Software error: Warning 330: Unable to open file (...) [Permission denied] at /idsShared.pm line 611." It would be better if IDS let me see the album and just warn me about the damaged file when i try to access it (or mail the admin, or whatever you find useful but not alerting users this way!). 2- In the album's thumbnails view, i think it is important to have a "NEXT" and a "PREVIOUS" page link, just because i am currently running directories with THOUSANDS photos (over 16000 photos in the entire gallery) and the album's page looks awful ie: http://earth-sky-water-fire.org/cgi-bin/ids/index.cgi?mode=album&album=/water/reefs%2cfishes%2csea%20life/small Users often get lost browsing those albums, and if i don't use very evident link colors it's very annoying figuring out which page is actually shown. Even worse: the page # links are not properly formatted, sometime they look very messy, unless you use monospaced fonts (ugly!!) what about tables? 3- I would love to customize the link of "main page" shown in each IDS generated page, as i have a quite complex homepage and i would not transform it into an IDS template (it also uses SSI and other CGIs..) 4- I would like to add a downloader helper to IDS, which takes the images from the server filesystem and gives them to users, without allowing direct downloading. This should be useful to implement other features, like access counters, download restrictions based for example on file size or system time (i did it with an humble workaround, but it works) and also anti-mirroring triggers and alerts. Well i know two things about this: first of all, it could affect performances, so it should be enabled only on sysadmin's demand, and then that all of these features could be implemented in other ways (apache directives, tiny patches, general purpose wrappers and so). However i find that having this feature built into IDS would be nice. 5- Sometime ago i saw a "static version" of ids floating around (maybe on your website) which was not supported by you. I suspect it worked "rendering" each webpage in the gallery and storing it on the disk into a static tree. I would love to have a look at it, because i could need to put up a mirror site for my collection on a CGI-less webserver. It could improve performances too, losing a bit of flexibility. Besides those little details, your program is great. Just one of the most powerful-yet-simple tools i've found around, and i am very happy with it. I am not a perl programmer, but as always i'll test your software on my quite big gallery, and can help you coding C helpers, if you wish. Best regards .asja -- as...@se... http://earth-sky-water-fire.org |
|
From: Jeff D. <je...@ba...> - 2001-11-08 02:22:31
|
> from scratch again about a week ago. I'm now using Apache::PageKit > (http://www.pagekit.org/) as the framework for IDS. Beware of HTML::Template, it leaks memory like a sieve under certain situations (refer to the sourceforge message board for that module). Jeff |
|
From: John M. <mo...@mu...> - 2001-11-08 00:40:59
|
Howdy! A beta of IDS 0.81 is now available: http://miranda.hn.org/ids-0.81b1.tar.gz This is primarily a bug fix release=96 hopefully the last one for this=20= code base. Here are the main changes: - works with ImageMagick 5.40 (This is what was causing all those "too=20= small" images.) - popup menus work both with and without JavaScript - file upload should now work on Windows servers - Swedish localization I'd appreciate your help testing this before it's released. Thanks to=20 all of you who contributed. Work on the IDS re-write is going well. As some of you know, I started=20= from scratch again about a week ago. I'm now using Apache::PageKit=20 (http://www.pagekit.org/) as the framework for IDS. This will allow me=20= to _easily_ add a ton of useful features, like support for users,=20 sessions, form validation, XML & XSLT, localization of content, a better=20= theme implementation, etc. Here's my progress so far: http://miranda.hn.org:8888/ mod_perl makes it quite fast! (Note that I've only been working on this=20= for around 10 hours, so you may experience some "unexpected features.") John |
|
From: Jack C. <ja...@ic...> - 2001-10-20 21:44:38
|
On Sat, Oct 20, 2001 at 03:31:37PM -0600, Ashley M. Kirchner wrote: > > It reports JPEGs that are 1600x1200 as being "1600x1200=>200x150" > > when "identify" is run on them. > > This causes them to be displated at 200x150 in IDS. > The question is, is this an IMagick bug, or "feature" ? And is it > for that specific size, or anything larger than that? I haven't had a > chance to install the latest IMagick yet, so I haven't done any testing. No, it does it for other images too. It's just that I have a 2.1 MPixel camera, so I have lots of 1600x1200 images. :) I think it's probably a "feature" for thumbnailing, but it doesn't play well with IDS. --Jack |
|
From: Jack C. <ja...@ic...> - 2001-10-20 21:27:51
|
It reports JPEGs that are 1600x1200 as being "1600x1200=>200x150" when "identify" is run on them. This causes them to be displated at 200x150 in IDS. --Jack |
|
From: Jack C. <ja...@ic...> - 2001-10-18 06:14:47
|
I have a bunch of files in and IDS that I recently upgraded from 0.51 to 0.8. The upgrade smoothly, except for the images are all now displayed at only 200x150 pixels. Looking in the albums directory: $ identify * #01_History.jpg JPEG 1600x1200=>200x150 DirectClass 8-bit 683kb 0.1u 0:01 #02_The_Falls.jpg[1] JPEG 1200x1600=>150x200 DirectClass 8-bit 487kb 0.1u 0:01 #03_Jack_and_the_Waterfall.jpg[2] JPEG 1600x1200=>200x150 DirectClass 8-bit 686kb 0.1u 0:01 #04_The_Drop.jpg[3] JPEG 1200x1600=>150x200 DirectClass 8-bit 409kb 0.0u 0:01 What does the 1600x1200=>200x150 mean? Is it some sort of resize built into the jpeg images? Can it be removed? --Jack |
|
From: Techwolf <Tec...@at...> - 2001-10-17 22:47:44
|
At 05:42 PM 10/17/2001 -0400, Jeff wrote: > 512M is not as much memory as it seems with modperl because each > httpd child can chew up many >double-digit megs of memory. I don't use modperl on servers with less >than a gig. It really depends >on how much traffic httpd is getting (how many children are spawned), how >frequently IDS is called, how >often the children are killed off, and some other things. Particularly >with the imagemagick stuff, >which uses oodles of memory when processing images, IDS has the potential >to go through quite a bit of >memory. If nothing else, set your MaxRequestsPerChild value very low >(like single digit). I got DoS by someone using GoZilla. It spawn enough processes at once that nearly 200M of swap was used up. Slowed the system to a keystroke a minute until I finally manage to kill httpd. Now I have child settings to a lot less then the default of 25. Currently at fixed 15 as that seems to a good setting for it. No swap used and somewhat faster service as childs does not have to spawn as its already in memory. I've tried 5 when I had less memory, but that was only handling two clients as most users are using keep-alive and that will tied up a connection until it times out. IE is defaulted to two keep-alive connections and four non-keep-alive connections. Would be nice if IDS had a max memory setting. *grins* Don't flame me, I know how nearly impossible that is with the current setup. Perhaps have IDS NOT call imakic for every hit as I think Imagic is the one chewing up the most resources. Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. |
|
From: Caleb E. <ca...@bk...> - 2001-10-17 21:50:21
|
On Wed, Oct 17, 2001 at 05:42:59PM -0400, Jeff wrote: > I didn't see a startup.pl file with IDS. The previous > poster detailed the httpd.conf > configuration necessary for > IDS, although the issue of the startup file and module > preloading was not > addressed. Sorry, left that part out. Here's my startup.pl, which contains some stuff not related to IDS (the MP3 stuff for use w/Apache::MP3, another fine mod_perl piece of code). -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. |
|
From: Jeff <je...@ba...> - 2001-10-17 21:43:05
|
On Wed, Oct 17, 2001 at 03:33:50PM -0500, Techwolf wrote:
> I thought IDS was already written to work with mod_perl. If so, how does
> one go about getting apache to run IDS under mod_perl. So simple a
> question, but I keep getting info on how to rewrite IDS, or other programs,
> to work with mod_perl. I don't want to do that, I just want to run IDS
> using mod_perl.
I didn't see a startup.pl file with IDS. The previous poster detailed the httpd.conf
configuration necessary for IDS, although the issue of the startup file and module preloading was not
addressed.
> I have read where one did get mod_perl to work with IDS, although as you
> said, eats up a bit of memory, but when my system has 512M, shouldn't be
> too much of a problem. *grins*
512M is not as much memory as it seems with modperl because each httpd child can chew up many
double-digit megs of memory. I don't use modperl on servers with less than a gig. It really depends
on how much traffic httpd is getting (how many children are spawned), how frequently IDS is called, how
often the children are killed off, and some other things. Particularly with the imagemagick stuff,
which uses oodles of memory when processing images, IDS has the potential to go through quite a bit of
memory. If nothing else, set your MaxRequestsPerChild value very low (like single digit).
Jeff
|
|
From: Techwolf <Tec...@at...> - 2001-10-17 21:16:39
|
At 04:43 PM 10/17/2001 -0400, Caleb Epstein wrote: > Unless you have specifically configured Apache to use mod_perl > on the IDS directory, its not in use. If you have a version > prior to the 1.0 beta it will NOT work under mod_perl. > Something like this (I have this inside a <VirtualHost> block): Thanks for the info. I am also using it under a virtual host. I thought the current version was mod_perl compatible. My bad. Now i'me just wondering if it will be still run under the same username and group as I have several sites on the same machine and use suexec of course. *grins* Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. |
7 messages has been excluded from this view by a project administrator.
