Announce: Enblend/Enfuse version 4.0 - Final Release
cspiel
Today we gladly announce the final
version of Enblend/Enfuse version 4.0. We have
put a tar-ball of it at
http://sourceforge.net/projects/enblend/files/
For convenience we also compiled binary archives
for the operating systems Windows (Thomas Modes)
and MacOSX (Ingemar Bergmark). The source
archive file on SourceForge is derived from
revision d394f60f8edf in the Mercurial
repository.
The web pages at
http://enblend.sourceforge.net/
have not been updated yet. They are undergoing
a major overhaul regarding their appearance as
well as the content management behind them. So
don't hold your breath.
In my last message as 4.0 Release Manager I
would like to thank all developers (in parti-
cular: Harry, Thomas, and Yuval), testers, and
proof-readers, who have contributed to the new
version. My personal thanks also go to the
enblending/enfusing smart asses and fly-by-night
hackers for getting the hell out of my way.
Have fun,
Chris
(Enblend/Enfuse 4.0 Release Manager)
Yuv
> The web pages at
> http://enblend.sourceforge.net/
> have not been updated yet. They are undergoing
> a major overhaul regarding their appearance as
> well as the content management behind them. So
> don't hold your breath.
The website is up [0] - beta quality. The content is mostly unchanged
(with the exception of the new and excellent 4.0 documentation
implemented by Chris) and the next step is an overhaul of the content.
After trying svgweb [1] (did not work / scale the graphic as intended)
I ended up with a solution that works on my Firefox/Ubuntu and should
also work in Opera, Safari, and Chrome (I don't have access / did not
test). I also added graceful degradation for legacy browsers, and even
for non-JavaScript browsers / search engines.
My aim was to keep DNA-resemblance with the previous version while
giving it a face-lift, updating the underlying technology, keeping it
simple / maintainable.
Because of the lacking support for SVG by the major player on the
browser market I limited the usage of SVG to the background only.
Initially I considered / wanted to use SVG for layout and content as
well, but this would have effectively required maintaining two
versions of the site. Maybe a few years down the road somebody in my
same situation will find a better / more welcoming and standards
abiding world. SVG rocks. Browsers that in 2010 do not support the SVG
standard suck, and the people that are responsible for the decision
not to support SVG in those browser suck even more.
There are still some issues, the most annoying being in my script
using xpath to transform the documentation (automatically generated
from source), resulting in some gibberish instead of html entitites
such as - if somebody knows how to fix this (the call to xpath
is in line 40 at [2].
I would like to solicit your feedback, specifically:
* I am very interested to know if/how it works/does not work with
other combination of browser/system than Firefox/Ubuntu that I develop
on; and how it looks on different sizes of screen, from smartphones to
xxl cinema displays.
* I have pushed the code to the repository [3]. Technical feedback and
improvements are welcome. If this can be made easier / simpler, I am
all for it. I have not implemented yet a cron job to push the
repository to the website.
* Last but not least, I also welcome critique of the design, although
I have no intention to make major changes to it. I know it is not
perfect, and there are subjective considerations as well. The usage of
browser default widgets for scrollbars and drop downs is IMHO ugly,
but functional and easier to maintain/update. Functions before
aesthetics.
And while I'm here via the web interface after a month long absence,
I'll have a look at what went on to see if it wakes up my interest to
join the conversation again.
Yuv
[0] http://enblend.sourceforge.net/
[1] http://code.google.com/p/svgweb/
[2] http://enblend.hg.sourceforge.net/hgweb/enblend/enblend-web/file/2ccfac410437/src/apply.sh
[3] http://enblend.hg.sourceforge.net/hgweb/enblend/enblend-web/
Yuv
> http://enblend.sourceforge.net/
> have not been updated yet. They are undergoing
> a major overhaul regarding their appearance as
> well as the content management behind them. So
> don't hold your breath.
The website is up [0] - beta quality. The content is mostly unchanged
Bart van Andel
Welcome back! Do you have a screenshot of what it's supposed to look
like? I'm using Chrome on WinVista but I've got the feeling what I see
is not exactly what you intended. Or it's just the beta thing, of
course.
* When resizing to an internal width (width of the background, as
reported by Chrome's Developer Tools feature) of less than about
500px, the news content won't fit anymore and will start falling
outside the screen. The horizontal scrollbar isn't of much use since
the orange div around the news section is just too small, and empty
space will be scrolled into the screen.
* When reducing the window width even further, the footer will start
moving out of visible screen space.
* Eventually also the menu will pop out of screen space, and the
window scrollbars (not the scrollbars inside the document) have to be
used to show it.
Normally these issues won't probably show up when using a regular PC
with a fair screen, but I guess for pocket devices this is an itch to
be scratched.
I'll check back tomorrow (maybe also on my Ubuntu install), time for
bed now.
--
Bart
> [2]http://enblend.hg.sourceforge.net/hgweb/enblend/enblend-web/file/2ccf...
> [3]http://enblend.hg.sourceforge.net/hgweb/enblend/enblend-web/
Tduell
On Dec 18, 5:46 pm, cspiel <csp...@freenet.de> wrote:
> Hello everybody!
>
> Today we gladly announce the final
> version of Enblend/Enfuse version 4.0. We have
> put a tar-ball of it at
> http://sourceforge.net/projects/enblend/files/
I have tried to build a FedoraRPM and get build errors:
File not found: /home/terry/rpmbuild/BUILDROOT/
enblend-4.0-0.fc12.x86_64/usr/share/info/enblend.info.gz
File not found: /home/terry/rpmbuild/BUILDROOT/
enblend-4.0-0.fc12.x86_64/usr/share/info/enfuse.info.gz
To build v3.2 we had the following in our spec file...
%files
%defattr(-, root, root, -)
%doc AUTHORS ChangeLog COPYING INSTALL NEWS README TODO VIGRA_LICENSE
%{_bindir}/enblend
%{_bindir}/enfuse
%{_mandir}/man1/enblend.1.gz
%{_mandir}/man1/enfuse.1.gz
%{_infodir}/*.info.gz
and to build v4.0 RC3 this had to be changed to...
%files
%defattr(-, root, root)
%doc AUTHORS ChangeLog COPYING INSTALL NEWS README VIGRA_LICENSE
# the following changes for v4.0 TLD 20091127
%{_bindir}/enblend
%{_bindir}/enfuse
%{_mandir}/man1/*
#%{_infodir}/* try the following
%{_infodir}/enblend.info.gz
%{_infodir}/enfuse.info.gz
Can you please point me to which man/info files are being built in
this final version, so that I can try to correct my spec file?
Cheers
Terry
cspiel
First of all, let me note that
Enblend/Enfuse 4.0 has _two_ configuration
systems:
1. Autoconf/Automake
2. CMake
The latter is still in experimental state, but
actively maintained by Kornel Benko.
The two systems do _not_ produce the same (set
of) files, neither do the utilize the same build
directory layouts. Consequently, your "*.spec"
files will look differently depending on whether
you take route 1 or route 2.
On Dec 19, 7:25 am, Tduell <tdu...@iinet.net.au> wrote:
> I have tried to build a FedoraRPM and get build errors:
> File not found: /home/terry/rpmbuild/BUILDROOT/
> enblend-4.0-0.fc12.x86_64/usr/share/info/enblend.info.gz
> File not found: /home/terry/rpmbuild/BUILDROOT/
> enblend-4.0-0.fc12.x86_64/usr/share/info/enfuse.info.gz
I'm only specialist for 1, and have no
idea about 2. So, I just assume for now you use
1.
- The autoconf/automake generated Makefile do not
produce gzipped info files.
- Control the generation of the info files with
the options "--enable-split-doc" xor
"--disable-split-doc". The latter produces
single, monolithic files.
- I recommend to use the automatically generated
manual files, "enblend.1" and "enfuse.1" in
the "src" sub-directory of your build
directory, and not the pre-build ones in the
original "src" directory.
- You can leave out "ChangeLog" as it is empty.
If you need help on using 2, please give Kornel
a buzz.
HTH,
Chris
Harry van der Wolf
On Dec 18, 1:46 am, cspiel <csp...@freenet.de> wrote:The website is up [0] - beta quality. The content is mostly unchanged
> The web pages at
> http://enblend.sourceforge.net/
> have not been updated yet. They are undergoing
> a major overhaul regarding their appearance as
> well as the content management behind them. So
> don't hold your breath.
(with the exception of the new and excellent 4.0 documentation
implemented by Chris) and the next step is an overhaul of the content.
The website works correctly on MacOSX Leopard (10.5.8) in Firefox 3.5.6 and in Safari 4.0.4.
Harry
Kornel Benko
Excelent.
But not everything is working here. I checked with konqueror and firefox, both show the same (bad) behaviour.
Try the following:
Select manual enblend 4.0
Select 3.2 Common options
Select (tab-panel) Response Files
This is what I got:
An error has been encountered in accessing this page.
1. Server: enblend.sourceforge.net
2. URL path: /enblend.doc/enblend_4.0.xhtml/Response-Files.html
3. Error notes: NONE
4. Error type: 404
5. Request method: GET
6. Request query string: NONE
7. Time: 2009-12-19 09:13:56 UTC (1261214036)
...
Directly from TOC selecting 3.1 Response Files works.
(Konqueror 4.3.2, Firefox 3.5.3 on ubuntu 64bit)
Kornel
--
Kornel Benko
Kornel...@berlin.de
Kornel Benko
> Hullo Chris,
>
> On Dec 18, 5:46 pm, cspiel <csp...@freenet.de> wrote:
> > Hello everybody!
> >
> > Today we gladly announce the final
> > version of Enblend/Enfuse version 4.0. We have
> > put a tar-ball of it at
> > http://sourceforge.net/projects/enblend/files/
>
> I have tried to build a FedoraRPM and get build errors:
> File not found: /home/terry/rpmbuild/BUILDROOT/
> enblend-4.0-0.fc12.x86_64/usr/share/info/enblend.info.gz
> File not found: /home/terry/rpmbuild/BUILDROOT/
> enblend-4.0-0.fc12.x86_64/usr/share/info/enfuse.info.gz
>
> To build v3.2 we had the following in our spec file...
> %files
> %defattr(-, root, root, -)
> %doc AUTHORS ChangeLog COPYING INSTALL NEWS README TODO VIGRA_LICENSE
> %{_bindir}/enblend
> %{_bindir}/enfuse
> %{_mandir}/man1/enblend.1.gz
> %{_mandir}/man1/enfuse.1.gz
> %{_infodir}/*.info.gz
This does not look like the default spec created if using "make package" in cmake build.
> and to build v4.0 RC3 this had to be changed to...
> %files
> %defattr(-, root, root)
> %doc AUTHORS ChangeLog COPYING INSTALL NEWS README VIGRA_LICENSE
> # the following changes for v4.0 TLD 20091127
> %{_bindir}/enblend
> %{_bindir}/enfuse
> %{_mandir}/man1/*
> #%{_infodir}/* try the following
> %{_infodir}/enblend.info.gz
> %{_infodir}/enfuse.info.gz
>
> Can you please point me to which man/info files are being built in
> this final version, so that I can try to correct my spec file?
In cmake-build:
enblend.info, enfuse.info (not gzipped)
Somehow the creation of man1 files got lost. I have to investigate :(
> Cheers
> Terry
Kornel Benko
> Somehow the creation of man1 files got lost. I have to investigate :(
Ok, found it. Corrected version in trunk now.
(My doing: The relevant part is from Thomas Modes, but I commited it with insufficient checking)
Benjamin Schnieders
the right - the background image is loaded, but not shown.
(see http://img684.imageshack.us/img684/3000/screenshotbc.png )
Yuv
On Dec 18, 7:47 pm, Bart van Andel <bavanan...@gmail.com> wrote:
> Welcome back!
not there yet.
> * When resizing to an internal width (width of the background, as
> reported by Chrome's Developer Tools feature) of less than about
> 500px, the news content won't fit anymore and will start falling
> outside the screen.
the non breaking spaces in the date. it's indeed a beta thing. will
think of a solution.
> * When reducing the window width even further, the footer will start
> moving out of visible screen space.
it's on the todo list, and it is because I (wrongly) pegged both
vertical and horizontal spacing to the dominant of the two scales (h/
v). have not come around to fix it yet.
> * Eventually also the menu will pop out of screen space, and the
> window scrollbars (not the scrollbars inside the document) have to be
> used to show it.
at some point it becomes inevitable. unless I resize the font as well,
but then it will become unreadable? don't know. work in progress.
> Normally these issues won't probably show up when using a regular PC
> with a fair screen, but I guess for pocket devices this is an itch to
> be scratched.
Yes. It's beta. It works for most cases, and we can go about solving
the little annoyances that it causes to less frequent cases.
Thanks for testing
Yuv
Yuv
On Dec 18, 7:47 pm, Bart van Andel <bavanan...@gmail.com> wrote:
> Welcome back!
not there yet.
> * When resizing to an internal width (width of the background, as
> reported by Chrome's Developer Tools feature) of less than about
> 500px, the news content won't fit anymore and will start falling
> outside the screen.
the non breaking spaces in the date. it's indeed a beta thing. will
think of a solution.
> * When reducing the window width even further, the footer will start
> moving out of visible screen space.
it's on the todo list, and it is because I (wrongly) pegged both
vertical and horizontal spacing to the dominant of the two scales (h/
v). have not come around to fix it yet.
> * Eventually also the menu will pop out of screen space, and the
> window scrollbars (not the scrollbars inside the document) have to be
> used to show it.
at some point it becomes inevitable. unless I resize the font as well,
but then it will become unreadable? don't know. work in progress.
> Normally these issues won't probably show up when using a regular PC
> with a fair screen, but I guess for pocket devices this is an itch to
> be scratched.
Yes. It's beta. It works for most cases, and we can go about solving
James Legg
> On Dec 18, 1:46 am, cspiel <csp...@freenet.de> wrote:
> > The web pages at
> > http://enblend.sourceforge.net/
> > have not been updated yet. They are undergoing
> > a major overhaul regarding their appearance as
> > well as the content management behind them. So
> > don't hold your breath.
>
> The website is up [0] - beta quality. The content is mostly unchanged
> (with the exception of the new and excellent 4.0 documentation
> implemented by Chris) and the next step is an overhaul of the content.
>
> * I am very interested to know if/how it works/does not work with
> other combination of browser/system than Firefox/Ubuntu that I develop
> on; and how it looks on different sizes of screen, from smartphones to
> xxl cinema displays.
The horizontal and vertical page scroll bars appear, although they only
show a small bit of white space. By default page down and spacebar
scrolls these page scroll bars, not the box in the middle. I have to
click in the content box after each page load to scroll the content.
This is on Firefox, Ubuntu, with a 1280x800 display, although it occurs
with the window any size below that too.
> * Last but not least, I also welcome critique of the design, although
> I have no intention to make major changes to it. I know it is not
> perfect, and there are subjective considerations as well. The usage of
> browser default widgets for scrollbars and drop downs is IMHO ugly,
> but functional and easier to maintain/update. Functions before
> aesthetics.
The white line in the background makes the bright text difficult to read
where it overlaps. The window needs to be fairly wide for this to
happen, and it only occurs on the downward curve on the left.
Personally, I prefer a long page with one vertical scrollbar at the edge
of the window rather than a fixed border with a scrollable window in the
middle. The scrollbar would be easier to use as at the edge of the
screen, and you could get more content on the screen at once.
-James
Yuv
On Dec 19, 7:20 am, Benjamin Schnieders
<benjamin.schnied...@gmail.com> wrote:
> on SeaMonkey 1.1.x, the whole top menu is shifted about a page width to
> the right - the background image is loaded, but not shown.
The screen looks like JavaScript was interrupted in the middle of
constructing the layout. Do you have access to a JavaScript console?
is there any error message?
Also: which background image is loaded - the SVG, or a bunch of PNGs?
The only thing I can see from the screenshot is that JavaScript
removed the default green background and the default message about
JavaScript not being enabled.
I check for SVG support with
document.implementation (see source code) and would hate to do a
browser detection based on its user agent string for browsers that
fall in between legacy and modern just because they have a buggy SVG
implementation (which may be a possibility). Do you know what is the
equivalent version of Firefox to SeaMonkey 1.1 (AFAIK they use the
same rendering engines)? Is SeaMonkey 1.1 recent? or when was it
released?
Yuv
Yuv
> The horizontal and vertical page scroll bars appear, although they only
> show a small bit of white space.
fixed.
> By default page down and spacebar
> scrolls these page scroll bars, not the box in the middle. I have to
> click in the content box after each page load to scroll the content.
fixed.
> The white line in the background makes the bright text difficult to read
> where it overlaps. The window needs to be fairly wide for this to
> happen, and it only occurs on the downward curve on the left.
bug. will fix. there should not be overlap.
> Personally, I prefer a long page with one vertical scrollbar at the edge
> of the window rather than a fixed border with a scrollable window in the
> middle. The scrollbar would be easier to use as at the edge of the
> screen, and you could get more content on the screen at once.
that's a completely different page paradigm, which has its pros and
cons. IIRC the reason why I settled on the fixed border paradigm had
to do with communication between XHTML and SVG - specifically my
inability to resize the SVG to the actual XHTML content beyond the
viewport. So I scaled the SVG to the viewport, and the content too.
To give you a bit more background about my choices: my main interest
in taking on the task of redesigning that website was to experiment
using SVG on the web, and if it was not for the lack of SVG support in
Internet Explorer you would not be seeing any XHTML at all.
Maintaining two versions (one SVG and one XHTML) is out of question,
so I used SVG for the background only. There are many cool things that
can be done in SVG, like [0] or [1], but it may still be a little bit
too early.
Yuv
[0] http://photopla.net/panospace/091014wpclock.svg
[1] http://www.photopla.net/photos.svg
Benjamin Schnieders
> The screen looks like JavaScript was interrupted in the middle of
> constructing the layout. Do you have access to a JavaScript console?
> is there any error message?
>
http://img686.imageshack.us/img686/5541/screenshotyl.png )
ewww.... just a moment, the _second_ time i load the page it looks like
http://img97.imageshack.us/img97/8720/screenshot2cc.png
back to the error messages, first try:
Warning: Unknown property '_overflow'. Declaration dropped. Source
File: http://enblend.sourceforge.net/enblend.css Line: 113
Error: document.getElementById("bkgnd") has no properties Source File:
http://enblend.sourceforge.net/layout.js Line: 100
which probably explains why the script stopped working.
the second time there was just the warning, no error message. could be
it's a problem with accessing an object before it is existent, so
(wildly guessing) maybe moving that piece of code into a function that
is called onLoad() might help.
> Also: which background image is loaded - the SVG, or a bunch of PNGs?
>
the SVG is loaded, i guess it also did yesterday.
> I check for SVG support with
> document.implementation (see source code) and would hate to do a
> browser detection based on its user agent string for browsers that
> fall in between legacy and modern just because they have a buggy SVG
> implementation (which may be a possibility). Do you know what is the
> equivalent version of Firefox to SeaMonkey 1.1 (AFAIK they use the
> same rendering engines)? Is SeaMonkey 1.1 recent? or when was it
> released?
>
the newest version is 2.0, but 1.1.17 still is the current version
included in the Ubuntu repositories.
SVG support should be all right, i think Mozilla could handle this even
long before there was Firefox :)
hope that helps,
Benjamin
Andreas Metzler
> Hello everybody!
> Today we gladly announce the final
> version of Enblend/Enfuse version 4.0.
[...]
Hello,
There seems to be a tiny bug in the tarball building script, the file
VERSION is not shipped. This breaks re-running of autoconf, since
configure.in reads the file's contents.
AC_INIT(enblend-enfuse,
[m4_esyscmd([tr -d '\n' < VERSION])],
[http://sourceforge.net/projects/enblend/])
cu andreas
Yuv
sorry I missed to answer this - going through the web based interface
is a pain.
On Dec 19, 4:17 am, Kornel Benko <Kornel.Be...@berlin.de> wrote:
> But not everything is working here. I checked with konqueror and firefox, both show the same (bad) behaviour.
> Try the following:
> Select manual enblend 4.0
> Select 3.2 Common options
> Select (tab-panel) Response Files
I am not sure where this error come from. These pages are all
automatically generated by the autotools with the 'make xhtml' target.
It seems to affect only the links at the node level (navigation) and I
understand too little of the automatic generated documentation to
understand why some pages link have .html in their links while others
have .xhtml.
I suspect the bug is in the enblend-enfuse repository (and tarball).
The switch from HTML documentation to XHTML documentation was made in
the very last minute before release.
Yuv
cspiel
Thanks a lot! It looks like you are the
first one who peeks inside the package and not
just drools over the new web layout.
On Dec 20, 2:47 pm, Andreas Metzler <ametz...@downhill.at.eu.org>
wrote:
> There seems to be a tiny bug in the tarball building script, the file
> VERSION is not shipped. This breaks re-running of autoconf, since
> configure.in reads the file's contents.
The bug was fixed in two ways.
1. In the hg repo with rev 741c9aa549cd
http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/741c9aa549cd
This is the clean solution, but it will not
be effective until 4.1.
2. I refreshed the tarball on SourceForge. This
is ugly (*), but it should help a lot of
people. When I was at it, I regenerated the
static manual pages in the "src" directory.
Thanks again,
Chris
(*) For the SCM non-wizards: The new tarball can
never be automatically regenerated from the
repo with e.g. "make dist". SCM wizards
become huffy when this happens.
Milan Knížek
> > I would like to solicit your feedback, specifically:
> > * I am very interested to know if/how it works/does not work with
> > other combination of browser/system than Firefox/Ubuntu that I develop
> > on; and how it looks on different sizes of screen, from smartphones to
> > xxl cinema displays.
>
> Personally, I prefer a long page with one vertical scrollbar at the edge
> of the window rather than a fixed border with a scrollable window in the
> middle. The scrollbar would be easier to use as at the edge of the
> screen, and you could get more content on the screen at once.
>
Same with me. On HTC Touch HD (screen 800x480 px, Opera), it is nearly
impossible to scroll the page as usual (by dragging the page upwards
with a finger touch), but it is needed to use a pencil and try to click
on the tiny scroll bars.
Regards,
Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)
Yuv
> James Legg píše v Ne 20. 12. 2009 v 01:29 +0000:
>
>
> impossible to scroll the page as usual
OK, got the message. Usability is important. Will move to a single
long page, no frame. I have a working proof of concept stretching the
SVG on Firefox. Not ready to be pushed on the site yet. Will try to
get it done before the end of the year.
Yuv
Bart van Andel
> OK, got the message. Usability is important. Will move to a single
> long page, no frame. I have a working proof of concept stretching the
> SVG on Firefox. Not ready to be pushed on the site yet. Will try to
> get it done before the end of the year.
In the past I've seen ways to use Javascript to determine the content
height, Google is your friend here, for example [0]. Can't you use
that to instruct the SVN to stretch? I haven't played around with it
myself but from my quick look at your code it seems Javascript already
drives the page quite intensively.
[0] http://codylindley.com/webdev/295/javascript-get-page-height-with-scroll
--
Bart
Pit Suetterlin
> The website is up [0] - beta quality. The content is mostly unchanged
> (with the exception of the new and excellent 4.0 documentation
> implemented by Chris) and the next step is an overhaul of the content.
Opera (10.10, on openSUSE 11.0): The scrollbar for the central content
box doesn't work. I cannot click-and-drag, neither does clicking in
the empty slider area work. At least most of the time not: On trying
several pages (clicking links does work), sometimes I got a
reaction/scroll of the content. However, it was delayed and not clear
what action had triggered the scroll.
CPU load is low during this.
Pit
--
Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit
Institute for Solar Physics
Tel.: +34 922 405 590 (Spain) P.Suet...@royac.iac.es
+46 8 5537 8507 (Sweden) Peter.Su...@astro.su.se
Yuv
> Try the following:
> Select manual enblend 4.0
> Select 3.2 Common options
> Select (tab-panel) Response Files
>
Christoph fixed this in the enblend-enfuse repository and tarball.
I've uploaded the fixed version. There are still issues with how I use
xpath to extract the content from the XHTML page, leading to garbage
characters instead of the previously existing html entities (e.g.
) but it is more useful than it was a week ago.
The layout without scrolling element in a div (James, Milan) is also
almost ready. Need to tweak some values / offsets and test it also in
the non-SVG version, then I'll upload it.
Yuv
Yuv
> of the window rather than a fixed border with a scrollable window in the
> middle.
done. not perfect, but good for some testing. feedback welcome.
Yuv