SciDAVis

Hi,

> when scripting is startet, the file
>  	/etc/scidavisrc.py
> cause an error message, because it cannot be compiled in /etc by
> a normal user. Is this really a config file? (I wouldn't dare change it!)

It's supposed to be a config file on the ground that users might want to 
change how the Python environment gets set up. Particularly, which special 
functions get imported from where. I guess it could be made more 
user-friendly, maybe by moving some of the stuff to a new file 
in /usr/share/scidavis and importing that. However, this would only make 
sense for some smaller parts such es the definition of import_to_global or 
the Qt API imports.

> If yes, it should be tagged as such (within Debian) an moved to a place
> like
>  	/etc/scidavis/scidavisrc.py
> such that it can be byte-compiled in the postinstall step.

Well, you can customize this path in scidavis.pro if that's where the config 
file should be on Debian.

> (Byte-compilation is done on a per-directory basis, AFAIK).

Not necessarily. There's a "compileall" module in the Python library that does 
what you say, but there's also "py_compile" for compiling single files. You 
can even run it as a script:

python /usr/lib/python2.5/py_compile.py /etc/scidavisrc.py

> And there should be a warning in the file that it has to be recompiled
> after a manual change, right?

It should be recompiled for reasons of startup time (although I guess, given 
its size, the difference won't be huge). If SciDAVis finds that the source 
file is newer than the byte-compiled one, it will try to re-compile and 
(failing that) simply run the new source file.

> However, I suspect that this file will not be changed, once the package
> is installed. Then a good place would be the in same directory as
>  	/usr/share/scidavis/scidavisUtil.py
> where byte-compilation is done anyway.

As I said above, there's some reasons why users may want to change 
scidavisrc.py: Add imports or function definitions, change which functions 
get imported from SciPy vs. GSL, eliminate some or all of the (numerous) 
imports to the global namespace.

Anyway, I'm open for suggestions how this file could be made less scary. 
Basically, it's really just a bunch of imports.

> Python's startup error is not fatal (scripting works, after all), but
> confusing.

The compilation error is checked for by SciDAVis, so we could change the error 
message. I guess completely supressing the error is not a good idea (in case 
someone expects compilation to happen and wonders what's going on), but we 
could add something below stating that it is non-fatal.

Knut

Hi,

ok, it is a config file.

I moved it to
 	/etc/scidavis/scidavisrc.py
and made sure that it is byte-compiled when the package is installed.
(There is a debhelper script which does it, if called with the _directory_
in question.)

After all, if an administrator knows how to change it, he should 
byte-compile it afterwards.
And if a normal user knows even better, he can copy it to 
$HOME/.scidavisrc.py and customise it there. It will be compiled
afterwards (I checked it).

Thanks for your clear explanations - I'm new to python, obviously.

Best regards,
Burkhard Bunk.
----------------------------------------------------------------------
  bunk@...      Physics Institute, Humboldt University
  fax:    ++49-30 2093 7628     Newtonstr. 15
  phone:  ++49-30 2093 7980     12489 Berlin, Germany
----------------------------------------------------------------------

On Tue, 29 Apr 2008, Knut Franke wrote:

> Hi,
>
>> when scripting is startet, the file
>>  	/etc/scidavisrc.py
>> cause an error message, because it cannot be compiled in /etc by
>> a normal user. Is this really a config file? (I wouldn't dare change it!)
>
> It's supposed to be a config file on the ground that users might want to
> change how the Python environment gets set up. Particularly, which special
> functions get imported from where. I guess it could be made more
> user-friendly, maybe by moving some of the stuff to a new file
> in /usr/share/scidavis and importing that. However, this would only make
> sense for some smaller parts such es the definition of import_to_global or
> the Qt API imports.
>
>> If yes, it should be tagged as such (within Debian) an moved to a place
>> like
>>  	/etc/scidavis/scidavisrc.py
>> such that it can be byte-compiled in the postinstall step.
>
> Well, you can customize this path in scidavis.pro if that's where the config
> file should be on Debian.
>
>> (Byte-compilation is done on a per-directory basis, AFAIK).
>
> Not necessarily. There's a "compileall" module in the Python library that does
> what you say, but there's also "py_compile" for compiling single files. You
> can even run it as a script:
>
> python /usr/lib/python2.5/py_compile.py /etc/scidavisrc.py
>
>> And there should be a warning in the file that it has to be recompiled
>> after a manual change, right?
>
> It should be recompiled for reasons of startup time (although I guess, given
> its size, the difference won't be huge). If SciDAVis finds that the source
> file is newer than the byte-compiled one, it will try to re-compile and
> (failing that) simply run the new source file.
>
>> However, I suspect that this file will not be changed, once the package
>> is installed. Then a good place would be the in same directory as
>>  	/usr/share/scidavis/scidavisUtil.py
>> where byte-compilation is done anyway.
>
> As I said above, there's some reasons why users may want to change
> scidavisrc.py: Add imports or function definitions, change which functions
> get imported from SciPy vs. GSL, eliminate some or all of the (numerous)
> imports to the global namespace.
>
> Anyway, I'm open for suggestions how this file could be made less scary.
> Basically, it's really just a bunch of imports.
>
>> Python's startup error is not fatal (scripting works, after all), but
>> confusing.
>
> The compilation error is checked for by SciDAVis, so we could change the error
> message. I guess completely supressing the error is not a good idea (in case
> someone expects compilation to happen and wonders what's going on), but we
> could add something below stating that it is non-fatal.
>
> Knut
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Scidavis-contributors mailing list
> Scidavis-contributors@...
> https://lists.sourceforge.net/lists/listinfo/scidavis-contributors
>

Hi Burkhard, hi Frank,

thanks for your interest in SciDAVis! We (the SciDAVis developers) are 
definitely interested in getting SciDAVis into the official Debian archive. 
(I am a Debian user myself BTW.)

The next release of SciDAVis (0.1.3) is planned for this weekend. We have 
already done several steps in order to make packaging easier in general. You 
can take a look at /branches/current_stable in the SVN repos. If we can do 
more, i.e., include Debian specific files, we'll gladly do so.

Best regards,
Tilman

Hi Burkhard, hi Tilman,

On Thursday 17 April 2008 19:28, Burkhard Bunk wrote:
> The software is still in rapid development, and the packages will need
> some revision to adhere to Debian policies. Actually, I'm not too
> familiar with this part of the game - I will need your help to quite
> some extend.

I've expected this and that is why I offered my help. We should move further 
discussion about (Debian specific) packaging off-list because it would be 
uninteresting for most people subscribed to scidavis-contributors. I'll 
contact you later.

On Thursday 17 April 2008 22:41, Tilman Benkert wrote:
> The next release of SciDAVis (0.1.3) is planned for this weekend. We have
> already done several steps in order to make packaging easier in general.
> You can take a look at /branches/current_stable in the SVN repos. If we can
> do more, i.e., include Debian specific files, we'll gladly do so.

Thanks for being proactive regarding packaging and making various improvements 
to ease this task! This is very welcome.

On Saturday 19 April 2008 22:55, Tilman Benkert wrote:
> For Debian, I have included the files from the 'debian' directory of
> Burkhard Bunk's latest package (with some small adjusments) in the source
> tarball and added a man page (the Debian policy says that the lack of a man
> page is considered a bug). This man page (actually it's an sgml source for
> docbook-to-man) can of course also be used by other distributions.

Thank you for including the man page, shipping an application without a man 
page is indeed a serious bug in Debian. But including the debian/ directory 
in the source tarball is from a Debian maintainer POV a bad idea. It is 
considered good packaging practice if upstream sources and Debian 
modifications are not in the same tarball but in a diff file accompanying the 
source tarball. I recommend to remove the debian/ directory from your SVN 
repository.

Thanks and congratulation for the new SciDAVis release!
Frank

Hi Frank,

> On Thursday 17 April 2008 19:28, Burkhard Bunk wrote:
> > The software is still in rapid development, and the packages will need
> > some revision to adhere to Debian policies. Actually, I'm not too
> > familiar with this part of the game - I will need your help to quite
> > some extend.
>
> I've expected this and that is why I offered my help. We should move
> further discussion about (Debian specific) packaging off-list because it
> would be uninteresting for most people subscribed to scidavis-contributors.
> I'll contact you later.
there is no reason to avoid the scidavis-contributors for such topics(, except 
of course when you don't want the public to read your post). The list is 
meant for everything remotely development related including translations, 
packaging, documenation writing etc.. If the list traffic gets too high 
(*dreaming of thousands of contributors*) we will simply add more mailing 
lists for specific topics.

> On Thursday 17 April 2008 22:41, Tilman Benkert wrote:
> > The next release of SciDAVis (0.1.3) is planned for this weekend. We have
> > already done several steps in order to make packaging easier in general.
> > You can take a look at /branches/current_stable in the SVN repos. If we
> > can do more, i.e., include Debian specific files, we'll gladly do so.
>
> Thanks for being proactive regarding packaging and making various
> improvements to ease this task! This is very welcome.
>
> On Saturday 19 April 2008 22:55, Tilman Benkert wrote:
> > For Debian, I have included the files from the 'debian' directory of
> > Burkhard Bunk's latest package (with some small adjusments) in the source
> > tarball and added a man page (the Debian policy says that the lack of a
> > man page is considered a bug). This man page (actually it's an sgml
> > source for docbook-to-man) can of course also be used by other
> > distributions.
>
> Thank you for including the man page, shipping an application without a man
> page is indeed a serious bug in Debian. But including the debian/ directory
> in the source tarball is from a Debian maintainer POV a bad idea. It is
> considered good packaging practice if upstream sources and Debian
> modifications are not in the same tarball but in a diff file accompanying
> the source tarball. I recommend to remove the debian/ directory from your
> SVN repository.
Ok, I'll remove the debian directory from the SVN repos and the source 
tarballs. If there is anything else apart from the manpage, the desktop file, 
and the mime type file you would like us to maintain, please let us know.

> Thanks and congratulation for the new SciDAVis release!
Thanks!

Tilman

congratulations!

-Quentin

Am Mittwoch, 16. April 2008 22:50:11 schrieb Tilman Benkert:
> Hi everyone,
>
> just in case someone wonders who "Tilman Benkert" is:
> Well, I got married last weekend and I gave up "Hoener zu Siederdissen" in
> favor of my wife's last name.
>
> Best regards,
> Tilman
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
>one _______________________________________________
> Scidavis-contributors mailing list
> Scidavis-contributors@...
> https://lists.sourceforge.net/lists/listinfo/scidavis-contributors

Hi Tilman,

> just in case someone wonders who "Tilman Benkert" is:
> Well, I got married last weekend and I gave up "Hoener zu Siederdissen" in
> favor of my wife's last name.

Congratulations from me, too! :-)

Knut

Thanks to both of you!

Tilman

Hi Frank,

> SciDAVis currently looks for translation files in
> qApp->applicationDirPath() + "/translations". This means that if scidavis
> is installed in /usr/bin/ it expects translations to be in
> /usr/bin/translations/. Most distributions do not allow subdirs in
> /usr/bin/, therefore it would be nice if this could be changed. Since the
> translation files are not architecture
> dependent /usr/share/scidavis/translations seems to be a good place to put
> translation files on Unix-like systems.
this has been addressed already. The location of the translations will be 
customizable in the .pro file from the next release on. See also:
https://sourceforge.net/tracker/index.php?func=detail&aid=1887021&group_id=199120&atid=968217

Best regards,
Tilman

Hi Tilman,

On Friday 11 April 2008 18:46, Tilman Hoener zu Siederdissen wrote:
> this has been addressed already. The location of the translations will be
> customizable in the .pro file from the next release on. See also:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1887021&group_id=
>199120&atid=968217

Ok, great. I should have checked the bug tracker before posting.
Sorry for the noise. 

Cheers,
Frank

Hi Tilman,

> 1) I think it's time to release SciDAVis 0.1.3. As I am quite busy this and
> the next weekend, I would make the release in two weeks unless you want to
> do that.
Yes, it's time to get the latest improvements out. Unfortunately, I'm also a 
bit busy, so probably it'll have to wait two more weeks.

> Concerning the bugs, that are still open: 
>  a) #1927200 "some peanuts...": Since we need to rewrite the dialogs for
> 0.3.0 anyway, I would postpone these "peanuts".
I agree that changing the dialogs should be postponed. As for the first item 
(no auto-rescaling when data changes), this is trivial to fix and (after some 
consideration) I think it is valid - auto-rescaling can be pretty annoying if 
you've spent some time fine-tuning ranges. And if you really do want the 
scaling adjusted, you just need to press the "Best fit" button.

>  b) #1903021 "Axis of 3D color map legend is broken": I actually don't know
> what you mean by that bug. On my system the color map legend looks ok.
Oops, forgot to close that one after filing a bug report against QwtPlot3D.

>  c)  #1887925 "Cannot export graph to PS/EPS": Unconfirmed so far. Works
> for me.
I also failed to reproduce the crashes, and I'm not sure what to do about the 
graphics quality issues. It's true that the default fonts are a bit small for 
printouts. On they other hand the font size is (ideally) supposed to be the 
same on screen and on paper, so if you print a 8x5cm graph window to A4, the 
font size / graph size ratio will be quite different. Maybe we could enlarge 
the default axes label/number fonts a bit - for the benefit of new users, 
since they are already customizable.

> BTW: I think post 0.1.3 we should only make another 0.1.x release if
> critical bugs occur. It's about time we concentrate completely on getting
> the new features out that we have been working on in the trunk.
Agreed.

> 2) I vote for rejecting feature request #1926182 "Add third party library
> dll's into installer". This would blow up the zips by a factor of 10 or
> more. And it teaches the wrong behavior IMHO. It's also not our job to
> correct the lack of a package manager on windows. I absolutely don't mind
> though if anyone else wants to provide the webspace to host these
> "packages" and we put a link on the homepage.
It would certainly be wrong for Linux, but manually downloading dependencies 
is simply a nuisance, for those who just want to give SciDAVis a try as well 
as for those who might want to install it on more than one computer. 
Therefore I think we should follow the example of most other Windows software 
and do make some effort to correct for the lack of a package manager. 
Particularly since I'm not aware of any actual size constraints on SF.net 
file releases - have I missed something?

Mauricio has sent me an installation script for the nullsoft installer 
(nsis.sf.net). The compiled installer is currently 17MB (roughly a factor of 
10, yes), but I think some of the libraries can be left out (Qt debug, QtSql, 
QtXml, static fit plugin libs). I'll try to upload a trimmed-down installer 
this evening. If that's okay with Maurcio, I'd also like to add the script to 
SVN, adding a GPL/copyright statement (currently, there's no copyright or 
license note in the script). That way, anyone can help with updating and 
maybe improving.

Apropos improvements: I think the best solution (short of writing a decent 
package manager for Windows) would be to include an option in the installer 
to pull Python and Qt from their official sites and include the other libs in 
the distribution. Of course, someone would have to implement and maintain 
this. Until then, I think including some third-party libraries is the least 
evil.

> 3) In the documentation of AbtractPart::view() you have written:
> "Parts must not depend on the existence of a view for their operation." At
> the moment this rule is broken in Table and Matrix as many methods assume
> that the view is created beforehand. Is there really a reason to be so
> strict or can we change "existance" to "visibility"?
If this can be done without too much extra work, I'd like to keep the strict 
formulation and adapt the relevant code. I think it helps us keep a clear 
seperation between parts and views, and it would make script-driven handling 
of parts more efficient. Maybe it's just a case of replacing some method 
calls with signals?

Knut

Hi Knut,

> > 1) I think it's time to release SciDAVis 0.1.3. As I am quite busy this
> > and the next weekend, I would make the release in two weeks unless you
> > want to do that.
>
> Yes, it's time to get the latest improvements out. Unfortunately, I'm also
> a bit busy, so probably it'll have to wait two more weeks.
ok, so I'll release v0.1.3 in two weeks.

> > Concerning the bugs, that are still open:
> >  a) #1927200 "some peanuts...": Since we need to rewrite the dialogs for
> > 0.3.0 anyway, I would postpone these "peanuts".
>
> I agree that changing the dialogs should be postponed. As for the first
> item (no auto-rescaling when data changes), this is trivial to fix and
> (after some consideration) I think it is valid - auto-rescaling can be
> pretty annoying if you've spent some time fine-tuning ranges. And if you
> really do want the scaling adjusted, you just need to press the "Best fit"
> button.
Ok, good.

> > 2) I vote for rejecting feature request #1926182 "Add third party library
> > dll's into installer". This would blow up the zips by a factor of 10 or
> > more. And it teaches the wrong behavior IMHO. It's also not our job to
> > correct the lack of a package manager on windows. I absolutely don't mind
> > though if anyone else wants to provide the webspace to host these
> > "packages" and we put a link on the homepage.
>
> It would certainly be wrong for Linux, but manually downloading
> dependencies is simply a nuisance, for those who just want to give SciDAVis
> a try as well as for those who might want to install it on more than one
> computer. Therefore I think we should follow the example of most other
> Windows software and do make some effort to correct for the lack of a
> package manager. Particularly since I'm not aware of any actual size
> constraints on SF.net file releases - have I missed something?
I just checked. It seems we only have a limit on the webspace, not in the 
download section. So, the size is not a problem. 
But what about Python, SIP, PyQt? Will it work properly if just copied 
somewhere rather than installed by their installers? 

> Mauricio has sent me an installation script for the nullsoft installer
> (nsis.sf.net). The compiled installer is currently 17MB (roughly a factor
> of 10, yes), but I think some of the libraries can be left out (Qt debug,
> QtSql, QtXml, static fit plugin libs). I'll try to upload a trimmed-down
> installer this evening. If that's okay with Maurcio, I'd also like to add
> the script to SVN, adding a GPL/copyright statement (currently, there's no
> copyright or license note in the script). That way, anyone can help with
> updating and maybe improving.
>
> Apropos improvements: I think the best solution (short of writing a decent
> package manager for Windows) would be to include an option in the installer
> to pull Python and Qt from their official sites and include the other libs
> in the distribution. Of course, someone would have to implement and
> maintain this. 
Yes, that would be the best solution. Just like Qt does it for MinGW.

>Until then, I think including some third-party libraries is
> the least evil.
What about including a HTML file with the direct links to the installers?
So, just doubleclick the HTML file, click on the 3 or 4 links and say "yes" 
(when the browser asks) to open the executable. Wouldn't that be easy enough? 

> > 3) In the documentation of AbtractPart::view() you have written:
> > "Parts must not depend on the existence of a view for their operation."
> > At the moment this rule is broken in Table and Matrix as many methods
> > assume that the view is created beforehand. Is there really a reason to
> > be so strict or can we change "existance" to "visibility"?
>
> If this can be done without too much extra work, I'd like to keep the
> strict formulation and adapt the relevant code. I think it helps us keep a
> clear seperation between parts and views, and it would make script-driven
> handling of parts more efficient. Maybe it's just a case of replacing some
> method calls with signals?
Ok, I'll adjust Table and Matrix accordingly.

Best regards,
Tilman

2008/4/6, Tilman Hoener zu Siederdissen <thzs@...>:
>
> Hi Knut,
>
>
> > > 1) I think it's time to release SciDAVis 0.1.3. As I am quite busy
> this
> > > and the next weekend, I would make the release in two weeks unless you
> > > want to do that.
> >
> > Yes, it's time to get the latest improvements out. Unfortunately, I'm
> also
> > a bit busy, so probably it'll have to wait two more weeks.
>
> ok, so I'll release v0.1.3 in two weeks.
>
>
> > > Concerning the bugs, that are still open:
> > >  a) #1927200 "some peanuts...": Since we need to rewrite the dialogs
> for
> > > 0.3.0 anyway, I would postpone these "peanuts".
> >
> > I agree that changing the dialogs should be postponed. As for the first
> > item (no auto-rescaling when data changes), this is trivial to fix and
> > (after some consideration) I think it is valid - auto-rescaling can be
> > pretty annoying if you've spent some time fine-tuning ranges. And if you
> > really do want the scaling adjusted, you just need to press the "Best
> fit"
> > button.
>
> Ok, good.
>
>
> > > 2) I vote for rejecting feature request #1926182 "Add third party
> library
> > > dll's into installer". This would blow up the zips by a factor of 10
> or
> > > more. And it teaches the wrong behavior IMHO. It's also not our job to
> > > correct the lack of a package manager on windows. I absolutely don't
> mind
> > > though if anyone else wants to provide the webspace to host these
> > > "packages" and we put a link on the homepage.
> >
> > It would certainly be wrong for Linux, but manually downloading
> > dependencies is simply a nuisance, for those who just want to give
> SciDAVis
> > a try as well as for those who might want to install it on more than one
> > computer. Therefore I think we should follow the example of most other
> > Windows software and do make some effort to correct for the lack of a
> > package manager. Particularly since I'm not aware of any actual size
> > constraints on SF.net file releases - have I missed something?
>
> I just checked. It seems we only have a limit on the webspace, not in the
> download section. So, the size is not a problem.
> But what about Python, SIP, PyQt? Will it work properly if just copied
> somewhere rather than installed by their installers?
>
>
> > Mauricio has sent me an installation script for the nullsoft installer
> > (nsis.sf.net). The compiled installer is currently 17MB (roughly a
> factor
> > of 10, yes), but I think some of the libraries can be left out (Qt
> debug,
> > QtSql, QtXml, static fit plugin libs). I'll try to upload a trimmed-down
> > installer this evening. If that's okay with Maurcio, I'd also like to
> add
> > the script to SVN, adding a GPL/copyright statement (currently, there's
> no
> > copyright or license note in the script). That way, anyone can help with
> > updating and maybe improving.
> >


Hi, I'm  agree, just add GPL statement and add the script to SVN.
There are a lot of things for to improve in the script but I just learn
about nsis scripting.
I think the installation on windows would be very easy for end users. This
people could be popular to scidavis and to report some bugs and features
requests. This would be useful for scidavis development, I guess.

> Apropos improvements: I think the best solution (short of writing a decent
> > package manager for Windows) would be to include an option in the
> installer
> > to pull Python and Qt from their official sites and include the other
> libs
> > in the distribution. Of course, someone would have to implement and
> > maintain this.
>
> Yes, that would be the best solution. Just like Qt does it for MinGW.
>
>
> >Until then, I think including some third-party libraries is
> > the least evil.
>
> What about including a HTML file with the direct links to the installers?
> So, just doubleclick the HTML file, click on the 3 or 4 links and say
> "yes"
> (when the browser asks) to open the executable. Wouldn't that be easy
> enough?
>
>
> > > 3) In the documentation of AbtractPart::view() you have written:
> > > "Parts must not depend on the existence of a view for their
> operation."
> > > At the moment this rule is broken in Table and Matrix as many methods
> > > assume that the view is created beforehand. Is there really a reason
> to
> > > be so strict or can we change "existance" to "visibility"?
> >
> > If this can be done without too much extra work, I'd like to keep the
> > strict formulation and adapt the relevant code. I think it helps us keep
> a
> > clear seperation between parts and views, and it would make
> script-driven
> > handling of parts more efficient. Maybe it's just a case of replacing
> some
> > method calls with signals?
>
> Ok, I'll adjust Table and Matrix accordingly.
>
> Best regards,
>
> Tilman
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Scidavis-contributors mailing list
> Scidavis-contributors@...
> https://lists.sourceforge.net/lists/listinfo/scidavis-contributors
>

Hi,

I've just replaced the zipped Windows binaries with a first version of the 
installer. Some details could be improved, though:

> But what about Python, SIP, PyQt? Will it work properly if just copied
> somewhere rather than installed by their installers?

I think the main problem here is that many users will want to use an existing 
Python installation with all sorts of third-party modules. The current 
installer avoids these problems by requiring users to install Python, SIP and 
PyQt manually. I don't think that these three can sensibly included in the 
installer.

> > Mauricio has sent me an installation script for the nullsoft installer
> > (nsis.sf.net). The compiled installer is currently 17MB (roughly a factor
> > of 10, yes), but I think some of the libraries can be left out (Qt debug,
> > QtSql, QtXml, static fit plugin libs).

I got it down to 7 MB. I'm mystified as to where QtSql and QtXml get pulled 
in, but without them SciDAVis refuses to start. So these are still included.

> > Apropos improvements: I think the best solution (short of writing a
> > decent package manager for Windows) would be to include an option in the
> > installer to pull Python and Qt from their official sites and include the
> > other libs in the distribution. Of course, someone would have to
> > implement and maintain this.
>
> Yes, that would be the best solution. Just like Qt does it for MinGW.

The nullsoft installation system supports downloading files, so this should be 
feasible.

> What about including a HTML file with the direct links to the installers?
> So, just doubleclick the HTML file, click on the 3 or 4 links and say "yes"
> (when the browser asks) to open the executable. Wouldn't that be easy
> enough?

That could be an easy solution, but where would we put this file?

Knut

Hi Mauricio,

> There are a lot of things for to improve in the script but I just learn
> about nsis scripting.

There's always something left to improve. ;-)

> I think the installation on windows would be very easy for end users. This
> people could be popular to scidavis and to report some bugs and features
> requests. This would be useful for scidavis development, I guess.

I agree. Thanks a lot for contributing the installer! :-) Your script is now 
(with some details changed) available at

http://scidavis.svn.sourceforge.net/viewvc/scidavis/branches/current_stable/scidavisScriptInstall.nsi?view=markup

Knut

Hi, Thanks for all to you. Some suggestions only about the web site. May be
is good to add some text about the windows installer option without the need
of download and install any extra library.
Also, is it possible to notify in other sites the existence the scidavis for
windows? For example in softpedia or something like that.
Ah, and in the packager people for windows my name, ;) :P
I'll try to improve the installer for the next release of scidavis on 2 or 3
weeks. I want to add the option for to install python and download and
install the manual for scidavis and the translations options for scidavis.


2008/4/6, Knut Franke <Knut.Franke@...>:
>
> Hi Mauricio,
>
>
> > There are a lot of things for to improve in the script but I just learn
> > about nsis scripting.
>
>
> There's always something left to improve. ;-)
>
>
> > I think the installation on windows would be very easy for end users.
> This
> > people could be popular to scidavis and to report some bugs and features
> > requests. This would be useful for scidavis development, I guess.
>
>
> I agree. Thanks a lot for contributing the installer! :-) Your script is
> now
> (with some details changed) available at
>
>
> http://scidavis.svn.sourceforge.net/viewvc/scidavis/branches/current_stable/scidavisScriptInstall.nsi?view=markup
>
>
> Knut
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Scidavis-contributors mailing list
> Scidavis-contributors@...
> https://lists.sourceforge.net/lists/listinfo/scidavis-contributors
>

Hi,

> Hi, Thanks for all to you. Some suggestions only about the web site. May be
> is good to add some text about the windows installer option without the
> need of download and install any extra library.

I've added a special download page for the Windows installer, with links to 
Python and PyQt (the PyQt installer includes SIP).

> Also, is it possible to notify in other sites the existence the scidavis
> for windows? For example in softpedia or something like that.

SciDAVis is already listed on a few sites (e.g. freshmeat.net and 
qt-apps.org). I'll also have a look it Softpedia on of the next days. Don't 
hesitate to register it on any other sites you may know.

> Ah, and in the packager people for windows my name, ;) :P

Cui honorem, honorem. :-)

> I'll try to improve the installer for the next release of scidavis on 2 or
> 3 weeks. I want to add the option for to install python and download and
> install the manual for scidavis and the translations options for scidavis.

That would be great. All of the necessary information is now on the Windows 
download page, but having it all in the installer would add a nice touch and 
sites like Softpedia could link to the installer directly.

Knut

2008/4/7, Knut Franke <Knut.Franke@...>:
>
> Hi,
>
>
> > Hi, Thanks for all to you. Some suggestions only about the web site. May
> be
> > is good to add some text about the windows installer option without the
> > need of download and install any extra library.
>
>
> I've added a special download page for the Windows installer, with links
> to
> Python and PyQt (the PyQt installer includes SIP).


mmm... ok, but it is some difficult to find, I guess. I wanted to find the
link in the download section of scidavis web site. That's all.
See you


> Also, is it possible to notify in other sites the existence the scidavis
> > for windows? For example in softpedia or something like that.
>
>
> SciDAVis is already listed on a few sites (e.g. freshmeat.net and
> qt-apps.org). I'll also have a look it Softpedia on of the next days.
> Don't
> hesitate to register it on any other sites you may know.
>
>
> > Ah, and in the packager people for windows my name, ;) :P
>
>
> Cui honorem, honorem. :-)
>
>
> > I'll try to improve the installer for the next release of scidavis on 2
> or
> > 3 weeks. I want to add the option for to install python and download and
> > install the manual for scidavis and the translations options for
> scidavis.
>
>
> That would be great. All of the necessary information is now on the
> Windows
> download page, but having it all in the installer would add a nice touch
> and
> sites like Softpedia could link to the installer directly.
>
>
> Knut
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Scidavis-contributors mailing list
> Scidavis-contributors@...
> https://lists.sourceforge.net/lists/listinfo/scidavis-contributors
>

> mmm... ok, but it is some difficult to find, I guess. I wanted to find the
> link in the download section of scidavis web site. That's all.

You're right, the download page was outdated. Thanks for the hint.

Knut