zim-wiki team mailing list archive

[Brendan Kidwell <snarf@xxxxxxxxx>]

(Sending again... Sigh! Why doesn't Gmail default to reply-all when the
original message is on a mailing list?)

On Mon, Mar 8, 2010 at 3:26 PM, Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx
> wrote:

> Nice ! I think many users will be very grateful.
>

Yes, I know quite a few myself.


> I think I will merge build-win32.py with setup.py, so it can be called
> as './setup.py py2exe'. ...


> For all windows specific build files I would put them directly under
> ./windows/
> this directory would then be more or less  parallel to the ./debian/
> directory.
>

Okay, so we'll merge the build script for Windows (which produces
encapsulated python byte code + python vm in an .exe with supporting files)
into setup.py. I will keep the install package builder (which produces the
Windows setup .exe) in a separate script under ./windows and that script
will produce a single file in ./dist . The products of these scripts will of
course not be subject to version control.

By the way Jaap I might want to patch the startup code in zim.py to look an
empty file called "./is-portable-install" and if it exists do some special
things such as create and/or open "../Notebooks/Default" relative to zim.exe
. I haven't figured out the details quite yet, but are you okay with adding
a kludge like that somewhere so that I don't end up with a separate
"compiled" python script as an .exe, to launch zim.exe? On the other hand I
might do most of the launch work with VBScript, JScript or Windows "batch
file" language.

For shell-integrated non-portable install mode, zim.exe already behaves
exactly right and we will not change this.

I think I'll put the details of how the Windows build process works
(basically documentation for developers) in the same folder as the the
Windows packager script. I'll merge a few lines of comment about the process
into ./README.txt .

I see you already figured out how to push a branch. Just put in a merge
> request
> through launchpad when it is ready for public consumption.


Will do. I need to spend the first half of the week catching up on homework.
Anyone who's waiting on the edge of your seat, be patient. :^) Or download
my branch and run the script yourself. :^)


> Looking at the hosting plan I would prefer keeping it a Google Code.
> Most linux users don't download directly from our site. But given the lack
> of a package management system on windows I suppose we would have
> to expect quite some direct downloads times 17Mb.
>

Agreed, the windows installer will be hosted at Google Code. A link will
placed/updated on the Zim public web site that directs the user to a LIST of
current (and past) Windows builds, so that I don't have to deal with telling
the web site maintainer the exact file name.

Or instead of Google Code, I might decide to move it to my personal web site
www.glump.net hosted at DreamHost. The hosting plan there can easily handle
a few thousand downloads of a 17MB installer per month, and this way there
won't be any confusion about where the source tree and bug tracker are -- I
really want all support requests to go through Launchpad, and someone can
triage to me if there is a Windows-specific problem that needs to be
addressed by me.

To explain the size of the package: The installer includes every piece of
python and GTK (and GTK icons and strings, internationalized) that are
actually used by code in Zim. As Jaap said, there is no package management
or centralized repository for Windows, so you have to include all the parts
with the installer. :^(


> I don't have a windows system available for private use, so if you are
> willing
> to support building windows releases I would be much obliged.


Then I'm the Windows build maintainer.

 > Oh and one more thing! There's a tiny bit in the NSIS script that's not
> > automated: ... Comments on this, anyone?
>
Not me - anyone else ?
>

If it's no more often than once every two weeks, I'll just do it manually.

Brendan Kidwell