Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Dotan Cohen]

On Sun, Mar 7, 2010 at 10:53, Brendan Kidwell  wrote:
> And yet another comment:
> The installer has a "Portable" mode where you must specify the target folder
> and it does not do any desktop/shell integration. I haven't tested this yet,
> but it should work fine right out of the box. I might write a little wrapper
> script to launch a default notebook in some path relative to the binary's
> folder (for the case with executable + notebook data as folders under Zim on
> your thumbdrive). We should have something to publish on portableapps.com
> "real soon now".
>

I have tried to run the 0.49 installer [1] in the hopes of installing
the portable version on my USB stick, however, the installer needs
admin privlidges. For  users with no access to an Admin Windows
account (quite the reason for needing a portable version), what
solutions are there to install Portable Zim?

Thanks.

[1] http://www.glump.net/software/zim

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Jaap Karssenberg]

On Mon, Mar 8, 2010 at 10:23 PM, Brendan Kidwell  wrote:
... 8< ...
> 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.
... 8< ...

Sure no problem. We can always clean it up a bit later on if it is a
real dirty hack. First step is to make it work.

If possible I would prefer either having this setting by checking an
environment variable or as a setting in one of the config files.

Probably an environment variable makes most sense assuming you need to
know that you are portable before looking for the config files.
Assuming you need a batch script or similar to set the XDG parameters
anyway, it would make sense to set an additional parameter which is
checked by zim.

Regards,

Jaap

___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Brendan Kidwell]

(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  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
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Jaap Karssenberg]

On Sun, Mar 7, 2010 at 9:45 AM, Brendan Kidwell  wrote:
> At long last, I have a working NSIS-based installer for Zim 0.4x for
> Windows. Thanks very much to Eugene Schava for submitting build-win32.py
> back in January.

Nice ! I think many users will be very grateful.

> Here's what I have:
> * README-BUILD-win32.txt -- explains where to get all the dependencies
> (GTK+, PyGTK, Bazaar, NSIS) and how to run the build and package scripts.
> * build-win32.py -- I had to add a couple of lines of code here on top of
> what Eugene wrote.
> * create-zim-setup.nsi -- NSIS installer build script
> * register-extension.nsh -- NSIS function to register a file type in the
> Windows shell
> * zim-logo-big.bmp -- big logo for Setup wizard
> create-zim-setup.nsi creates an installer package (.exe) in
> ./windows/release, with a size of about 17MB.
> My questions are these:
> Due to the excellent support of Windows from the Python ecosystem, very
> little needs to be added to the pyzim source tree to support building a
> binary for Windows and packaging for Windows. Therefore, we should integrate
> my additions directly into the pyzim source tree. Correct?
> If so, where exactly will they go? Right now I've got
> README-BUILD-win32.txt
> build-win32.py
> --> in ./
> create-zim-setup.nsi
> register-extensionnsh
> zim-logo-big.bmp
> --> in ./windows/build
> Should *.nsi, *.nsh and *.bmp really in ./windows/build? Where would you put
> them, Jaap, if you were doing this?

I think I will merge build-win32.py with setup.py, so it can be called
as './setup.py py2exe'.
Also I will merge README-BUILD-win32.txt with the generic README.txt .

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.

The py2exe script could probably target ./py2exe/ as build directory.

The installer itself should end up in ./dist/ like all other archives
for distribution.
(Only reason not to have py2exe target ./dist/ is that it does not
produce a single file,
but a directory.)

> Is "README-BUILD-win32.txt" named correctly? (Again, it's a list of
> instructions for installing dependencies and creating the installer
> package.)
> I assume I should follow standard Bazaar procedure outline here
> http://doc.bazaar.canonical.com/latest/en/user-guide/sending_changes.html
> to submit my changes to you, once I'm ready, yes?

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.

> What about the installer .exe file? Who will host that? I don't mind having
> me personally take charge running the Windows build process a day or two
> after I see you announce a new Zim version, but I think it ought to be
> hosted directly at
> http://zim-wiki.org/downloads/
> if 17MB isn't too much of a load on the web hosting provider. (If it is,
> then let's keep it at Google Code where I published my installer for the
> Perl version last year.) What do I need to do with my installer to get it
> published on zim-wiki.org? Alternative Jaap if you have direct easy access
> to a reliable Windows system, you can do the build and take me out of the
> loop if you'd like.

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.

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.

> Oh and one more thing! There's a tiny bit in the NSIS script that's not
> automated: the maintainer needs to manually enter the Zim version number and
> the official date tag for this build into the script source before running
> it. I don't have access to a Windows server that can perform automatic
> builds in response to Jaap checking in new code in lp:zim, so I'm not
> inclined to fix this shortcoming in the build process. If we DID want to go
> with automated builds, I could probably fix it so it set the version number
> and build date automatically. Comments on this, anyone?

Not me - anyone else ?

Regards,

Jaap

___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Jeffrey Liu]

Thank you Brendan!

On Sun, Mar 7, 2010 at 6:38 AM, Brendan Kidwell  wrote:

> On Sun, Mar 7, 2010 at 3:45 AM, Brendan Kidwell  wrote:
>
>> I assume I should follow standard Bazaar procedure outline here
>> http://doc.bazaar.canonical.com/latest/en/user-guide/sending_changes.html
>> to submit my changes to you, once I'm ready, yes?
>>
>
> Nevermind about that question. I'm starting to get over the learning curves
> of Bazaar and Launchpad. Pushed 
> lp:~bkidwell/zim/pyzim-win-installer
>  (not
> ready to merge yet!)
>
> I'm really starting to like these tools, but now I've been up all night and
> my school homework is beyond late. :^) Oh well.
>
>
> ___
> Mailing list: https://launchpad.net/~zim-wiki
> Post to : zim-wiki@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Brendan Kidwell]

On Sun, Mar 7, 2010 at 3:45 AM, Brendan Kidwell  wrote:

> I assume I should follow standard Bazaar procedure outline here
> http://doc.bazaar.canonical.com/latest/en/user-guide/sending_changes.html
> to submit my changes to you, once I'm ready, yes?
>

Nevermind about that question. I'm starting to get over the learning curves
of Bazaar and Launchpad. Pushed
lp:~bkidwell/zim/pyzim-win-installer
(not
ready to merge yet!)

I'm really starting to like these tools, but now I've been up all night and
my school homework is beyond late. :^) Oh well.
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Brendan Kidwell]

And yet another comment:

The installer has a "Portable" mode where you must specify the target folder
and it does not do any desktop/shell integration. I haven't tested this yet,
but it should work fine right out of the box. I might write a little wrapper
script to launch a default notebook in some path relative to the binary's
folder (for the case with executable + notebook data as folders under Zim on
your thumbdrive). We should have something to publish on
portableapps.com"real soon now".

On Sun, Mar 7, 2010 at 3:45 AM, Brendan Kidwell  wrote:

> At long last, I have a working NSIS-based installer for Zim 0.4x for
> Windows. Thanks very much to Eugene Schava for submitting build-win32.py
> back in January.
>
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

[Zim-wiki] working installer for Zim 0.4x on windows -- not published yet; I have questions

[Brendan Kidwell]

Hi Jaap,

At long last, I have a working NSIS-based installer for Zim 0.4x for
Windows. Thanks very much to Eugene Schava for submitting build-win32.py
back in January.

Here's what I have:
* README-BUILD-win32.txt -- explains where to get all the dependencies
(GTK+, PyGTK, Bazaar, NSIS) and how to run the build and package scripts.
* build-win32.py -- I had to add a couple of lines of code here on top of
what Eugene wrote.
* create-zim-setup.nsi -- NSIS installer build script
* register-extension.nsh -- NSIS function to register a file type in the
Windows shell
* zim-logo-big.bmp -- big logo for Setup wizard

create-zim-setup.nsi creates an installer package (.exe) in
./windows/release, with a size of about 17MB.

My questions are these:

Due to the excellent support of Windows from the Python ecosystem, very
little needs to be added to the pyzim source tree to support building a
binary for Windows and packaging for Windows. Therefore, we should integrate
my additions directly into the pyzim source tree. Correct?

If so, where exactly will they go? Right now I've got

README-BUILD-win32.txt
build-win32.py
--> in ./
create-zim-setup.nsi
register-extensionnsh
zim-logo-big.bmp
--> in ./windows/build

Should *.nsi, *.nsh and *.bmp really in ./windows/build? Where would you put
them, Jaap, if you were doing this?

Is "README-BUILD-win32.txt" named correctly? (Again, it's a list of
instructions for installing dependencies and creating the installer
package.)

I assume I should follow standard Bazaar procedure outline here
http://doc.bazaar.canonical.com/latest/en/user-guide/sending_changes.html
to submit my changes to you, once I'm ready, yes?

What about the installer .exe file? Who will host that? I don't mind having
me personally take charge running the Windows build process a day or two
after I see you announce a new Zim version, but I think it ought to be
hosted directly at
http://zim-wiki.org/downloads/
if 17MB isn't too much of a load on the web hosting provider. (If it is,
then let's keep it at Google Code where I published my installer for the
Perl version last year.) What do I need to do with my installer to get it
published on zim-wiki.org? Alternative Jaap if you have direct easy access
to a reliable Windows system, you can do the build and take me out of the
loop if you'd like.

Oh and one more thing! There's a tiny bit in the NSIS script that's not
automated: the maintainer needs to manually enter the Zim version number and
the official date tag for this build into the script source before running
it. I don't have access to a Windows server that can perform automatic
builds in response to Jaap checking in new code in lp:zim, so I'm not
inclined to fix this shortcoming in the build process. If we DID want to go
with automated builds, I could probably fix it so it set the version number
and build date automatically. Comments on this, anyone?

Brendan Kidwell
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp