soon 0.8.6

I am about to release the 0.8.6. It was mainly delayed because of
the bug in REXML in ruby 1.8.4. I discussed back and forth with
REXML's author in order to choose a good solution as to what to
do with this bug. I finally chose to just directly abort when
ruby version 1.8.4 is detected. Packagers of booh should probably
put a conflict with this version of Ruby.

Note that additionally, IMHO packagers of Ruby should not
release 1.8.4 (or include a fix for REXML).

Main differences in 0.8.6 include:

* [Till feature] add ability to split thumbnails on several
  pages

* [Pixel feature] be fully compatible with browsers with no
  javascript support

* generate a .htaccess file specifying the UTF-8 charset to try
  to workaround badly configured apache servers 

* [Benny feature] we can choose the best images size
  automatically with the browser window size instead of using the
  default (medium) size

* change CSS code so that image border color should now work in
  MSIE as well

* [RGS feature] don't do javascript key shortcuts when modifiers
  are pressed (control, alt, shift); this should avoid overriding

Re: soon 0.8.6

Le vendredi 14 avril 2006 à 01:18 +0200, Guillaume Cottenceau a écrit :
> I am about to release the 0.8.6. It was mainly delayed because of
> the bug in REXML in ruby 1.8.4. I discussed back and forth with
> REXML's author in order to choose a good solution as to what to
> do with this bug. I finally chose to just directly abort when
> ruby version 1.8.4 is detected. Packagers of booh should probably
> put a conflict with this version of Ruby.

Can you link to a description of the bug (either the main one or the
effect on booh), so that packagers can argue about their decisions (and
avoid usual cabale ? :)

thanks

_______________________________________________
Booh-discuss mailing list
Booh-discuss <at> zarb.org
https://www.zarb.org/mailman/listinfo/booh-discuss

Re: soon 0.8.6

Damien Krotkine <dams 'at' gentoo.org> writes:

> Le vendredi 14 avril 2006 à 01:18 +0200, Guillaume Cottenceau a écrit :
> > I am about to release the 0.8.6. It was mainly delayed because of
> > the bug in REXML in ruby 1.8.4. I discussed back and forth with
> > REXML's author in order to choose a good solution as to what to
> > do with this bug. I finally chose to just directly abort when
> > ruby version 1.8.4 is detected. Packagers of booh should probably
> > put a conflict with this version of Ruby.
> 
> Can you link to a description of the bug (either the main one or the
> effect on booh), so that packagers can argue about their decisions (and
> avoid usual cabale ? :)

A generic one might be found here:

https://www.zarb.org/pipermail/booh-discuss/2006-February/000146.html

While the ticket can be found here:

http://www.germane-software.com/projects/rexml/ticket/48

--

-- 
Guillaume Cottenceau - http://zarb.org/~gc/

0.8.6 and speed improvements

In front of the critical performance problems of booh (taking so
much time to generate an album), I have worked on speed
improvements.

Contrary to my belief, the performance problems were not related
to the fact that booh is written in ruby (I always tend to assume
such a thing... I always do the same mistake, same with perl).

They were due to the slowness of ImageMagick's identify (takes up
typically 35ms to identify a file, which I need to know the
dimensions of thumbnails so that browser can correctly render the
thumbnails page prior to downloading the images - using
Gdk::Pixbuf when available drops this figure down to 4ms) and to
the slowness of rexml (ruby's xml library) (this was solved by
preprocessing some content out of the per-image loops).

On my machine, regenerating an album for changes in a subalbum of
40 images is down from 28.5 secs to 5.0 secs.

--

-- 
Guillaume Cottenceau - http://zarb.org/~gc/

Re: 0.8.6 and speed improvements

Guillaume Cottenceau <gc4 <at> bluewin.ch> writes:

> On my machine, regenerating an album for changes in a subalbum of
> 40 images is down from 28.5 secs to 5.0 secs.

wooooowwwww. no reason anymore for booh not to rule dah world!

(ie as soon as i find the time to publish my latest holidays)

Re: 0.8.6 and speed improvements

On 26 Apr 2006 23:34:05 +0200, Guillaume Cottenceau <gc4 <at> bluewin.ch> wrote:
> In front of the critical performance problems of booh (taking so
> much time to generate an album), I have worked on speed
> improvements.
> [...]
> On my machine, regenerating an album for changes in a subalbum of
> 40 images is down from 28.5 secs to 5.0 secs.
>

Does this also improve the speed of Album delete, album move
up/down/top/bottom? On the version I used to generate my 6000pics
album, it was much faster using my text editor to alter the booh XML
file.
This is related to album preprocessing (before generation) so it
happens only 1 time in theory [1], but it is still *very* annoying to
wait 1 minute to move up an album...

Anyway, booh is still great and seems to become greater!

Julien

[1] booh-0.5 broke XML file structure compliance with older version,
so I had to configure again my albums...

[feat req] granular control of image placement / page views

Hello booh-discuss!

Kudos for the new release.

One feature which I miss is the ability to have a finer control over
image placement.
I know this feature is quite heavy to implement and may break loads of
stuff so maybe I should just check if such a software exists.

Here is a description of my needs:
The more I publish web albums, the more I want to have control over
what the viewer sees, I would like to be able to set the layout of the
pages myself. For example, say I have a webalbum of pictures of ski
holidays. Well, maybe I want the 1st page to display only one
panoramic picture of the mountains.
On the second page, I would introduce the team with "home pictures" of
all the members of the Kolkhoze crew (private joke inside), then on
the third and fourth page, I want to display acrobatic figures of dams
doing its patented "908768987° on the grab aerial flip flop reverse
with replaque on the teeth". On the next 3 pages I want to display
scans of gc's backspine and   pictures of the medical equipment needed
to sustain his life.
And so on.

IE, instead of just displaying images accoring to the number of images
by page the user wants to see, I need a "page" approach with the
possibility to have total control over the layout of the page, how
many image are displayed, their position...

As I said, I guess this requires heavy coding, but that's one hell of

Re: 0.8.6 and speed improvements

> > On my machine, regenerating an album for changes in a subalbum of
> > 40 images is down from 28.5 secs to 5.0 secs.
>
> Does this also improve the speed of Album delete, album move
> up/down/top/bottom? On the version I used to generate my 6000pics

No.

> album, it was much faster using my text editor to alter the booh XML
> file.

Yes, this is always the same slowness of rexml with large XML files
with non trivial accesses (xpath, parent, next node by element
name...).

6000 pics is a lot... you will probably never have fast processing
with it unless I totally drop using rexml (but last time I checked,
ruby-libxml was not features rich enough).

> This is related to album preprocessing (before generation) so it
> happens only 1 time in theory [1], but it is still *very* annoying to
> wait 1 minute to move up an album...

I understand and feel sorry but probably won't provide a solution
anytime soon :/

> Anyway, booh is still great and seems to become greater!

Thanks :)

Re: [feat req] granular control of image placement / page views

> One feature which I miss is the ability to have a finer control over
> image placement.
> I know this feature is quite heavy to implement and may break loads of
> stuff so maybe I should just check if such a software exists.
>
> Here is a description of my needs:
> The more I publish web albums, the more I want to have control over
> what the viewer sees, I would like to be able to set the layout of the
> pages myself. For example, say I have a webalbum of pictures of ski
> holidays. Well, maybe I want the 1st page to display only one
> panoramic picture of the mountains.
> On the second page, I would introduce the team with "home pictures" of
> all the members of the Kolkhoze crew (private joke inside), then on
> the third and fourth page, I want to display acrobatic figures of dams
> doing its patented "908768987° on the grab aerial flip flop reverse
> with replaque on the teeth". On the next 3 pages I want to display
> scans of gc's backspine and   pictures of the medical equipment needed
> to sustain his life.
> And so on.
>
> IE, instead of just displaying images accoring to the number of images
> by page the user wants to see, I need a "page" approach with the
> possibility to have total control over the layout of the page, how
> many image are displayed, their position...

Maybe you could live with half of it by using sub-albums: one
sub-album containing only one photo (the panoramic) then another one
with kholkoze presentation etc. Booh will present one thumbnail for
each of them and when you click you will see the images of the
"category".

domain name

http://www.booh.org/ is finally mine! yipee.

--
Guillaume Cottenceau - http://zarb.org/~gc/