Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 2008-02-26 at 07:24 -0800, Brian Dessent wrote: To really do this right (e.g. how MSI can rollback to the starting state midway through a aborted install) is a tremendous amount of work that I don't think anyone here is prepared to take on. FWIW this is why I started porting dpkg to cygwin, way back when - it was with the intent of getting a transaction packaging system without writing one from scratch. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [ITA] squid: Web Proxy Cache
On Mon, 2007-12-10 at 11:13 +0100, Corinna Vinschen wrote: On Dec 9 23:45, Dr. Volker Zell wrote: Hi I would like to adopt and maintain the squid package from Robert Collins. Cool, thanks! ... The file etc/defaults/etc/squid/squid.conf has CRLF line endings. Is that ok? Or do you want to change that first? It should; the cygwin port of squid understands that its on a basically windows platform. -Rob signature.asc Description: This is a digitally signed message part
Re: 6th summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Wed, 2005-10-26 at 11:43 +0200, Corinna Vinschen wrote: NOTE: This is one mail before the last on this matter. LIST 1: PACKAGES WITH UNCLEAR OWNERSHIP === dpkg Robert Collins or up for grabs? squid Robert Collins or up for grabs? I thought I had made this clear. Up for grabs. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, 2005-09-15 at 20:36 +0200, Gerrit P. Haase wrote: Christopher Faylor wrote: On Thu, Sep 15, 2005 at 07:41:24PM +0200, Corinna Vinschen wrote: On Sep 16 03:36, Robert Collins wrote: I'm still here, but not actively maintaining packages, offhand that means dpkg, squid probably need excising or new maintainers. Er... what does that mean, dpkg and squid have a maintainer or dpkg and squid have no maintainer? He's saying that they have no maintainer currently so they may need to be removed from the distribution. I use SquidNT quite happily, the native port has improved very much in the last one-two years, they even have included SSL support recently. Yes, Guido is doing a great job there, and I don't think any of us (upstream) are caring about bugs in the cygwin build at this point. Rob signature.asc Description: This is a digitally signed message part
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, 2005-09-15 at 18:45 +0200, Corinna Vinschen wrote: other maintainer without getting any notice from them. Since we have a couple of packages which haven't been updated for a good amount of time, there's apparently a need to find out, which packages are still maintained and which have lost their maintainer on the way. I'm still here, but not actively maintaining packages, offhand that means dpkg, squid probably need excising or new maintainers. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Welcoming Brian Dessent as setup maintainer
On Tue, 2005-05-03 at 21:00 -0400, Christopher Faylor wrote: On Wed, May 04, 2005 at 12:15:37AM +0100, Max Bowsher wrote: Brian Dessent wrote: that currently the local cache is keyed to the url. Another thing to discuss is whether that, itself, is a bug. It's not a bug, per se, since it was designed that way, wasn't it? So theres one key reason for the keying to URL: cache pollution. 3rd party sites with the same file name, different md5 - but matching their .ini file - should not be able to prevent you getting the package you wanted. Or worse getting their (as it passes their md5 entry) package without warning. Cheers, Rob signature.asc Description: This is a digitally signed message part
Re: setup.exe sucks
On Tue, 2004-12-07 at 15:16 -0500, Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Ack. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup RFC: Ditch homegrown http/ftp code and use a library?
On Sat, 2004-11-13 at 11:57 +0100, Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: * Package file scarcely ever change whilst keeping the same name. Also, they are compressed, so a small change is likely to cause the entire contents to change anyway. Therefore, rsync would not help. It could eb somewhat used anyways just doing a ln -s of the old file on the new name, THEN rsyncing it... I shoudl try but in theory it should read it for calculating the diff, then if writes a NEW file with the transfer and delete the old, so it would both have the pro of rsync and the pro of not copy the ACTUAL file (creating all the symlinks for every newer package in setup.ini is not so much work). In fact, I think I will try and do such a bash script to do this, to test the idea. Maybe only for packages ALREADY locally present. Calculating which file to use as a basis for rsync is easy without symlinks: Its just the 'closest to the version being downloaded'. Define closest as you would intuitively: two package files with the same x.y.z components are closer than two with the same x.y and different z. As for using rsync on package files, there is strong evidence from the debian project that it is marginal, unless you have the zlib with the patched hunk-reset which is much more likey to keep consistent data in successive minor releases of a package. For bz2, I don't know for sure, but I suspect a similar issue will apply. Rob signature.asc Description: This is a digitally signed message part
Re: setup RFC: Ditch homegrown http/ftp code and use a library?
On Sat, 2004-11-13 at 12:11 +0100, Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Collins wrote: Calculating which file to use as a basis for rsync is easy without symlinks: Its just the 'closest to the version being downloaded'. Define closest as you would intuitively: two package files with the same x.y.z components are closer than two with the same x.y and different z. In my idea symlinks were not used to select the version, just to let rsync think the file is already present locally, and with old file content, so that its content is used for optimization. Thats my point : rsync doesn't require the same file name to use the content for optimisation. You tell rsync what file to use as the basis, and what file to write to. Cheers, Rob signature.asc Description: This is a digitally signed message part
Re: setup RFC: Ditch homegrown http/ftp code and use a library?
On Sun, 2004-11-14 at 03:08 +0100, Lapo Luchini wrote: Robert Collins wrote: Thats my point : rsync doesn't require the same file name to use the content for optimisation. You tell rsync what file to use as the basis, and what file to write to. This, if you rsync one file at a time, but if you create the symlinks in every directory, then you can rsync the whole directory tree with a single command, and is much more efficient. (only one connection for all the files) Huh? Doing what I suggest has nothing to do with the # of connections, the protocol supports it completely. It might, if you are spawning rsync locally each time, with the file list option, you could (easily) add a new file destination list, and that would provide the single connection, custom basis approach. Anyway... this could lead to a more-optimized script to download most of it, not really to be included in setup so... Sure. Rob signature.asc Description: This is a digitally signed message part
Re: setup.exe sizes openldap-2-2-15
On Wed, 2004-10-27 at 04:03 +0200, Reini Urban wrote: Brian Dessent schrieb: Reini Urban wrote: Esp. Replaces: sh-utils fileutils textutils would be needed for coreutils. And it doesn't require additional user-input. It's not strictly necessary. There's already the _ZZZRemovedPackages thing where you can stick dummy empty packages of things that have gone away. Sure, but this is ugly, and Robert has already written most of the Replaces: codepath and much more. My upset patch for this is on the way (well, I attach it), and the setup.exe needs further testing. I'm glad that code is getting used now :) Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecificationhaveaprivatecopy-constructor? (Robert?)
On Wed, 2004-09-01 at 08:12 +0100, Max Bowsher wrote:
Robert Collins wrote:
Have you heard of the 'rule of 3' ?
No. Apparently I need to do some reading.
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.9
A class with any of {destructor, assignment operator, copy constructor}
generally needs all 3
Cheers,
Rob
signature.asc
Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have a privatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 08:54 +0100, Max Bowsher wrote:
So we have code like that at the moment?
Certainly. 4 occurrences in IniDBBuilderPackage.cc and 1 in package_db.cc.
Eh? I can't find any. We have things like
setSourcePackage(PackageSpecification(name));
which at the end of the call chain does:
_packageversion::setSourcePackageSpecification(PackageSpecification
const aSpec)
{
_sourcePackage=aSpec;
}
which should not invoke the copy contructor. rather it is the assignment
operator.
PackageSpecification operator= (PackageSpecification const );
which is public, and should be usable.
gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and
whatever warning you are getting is probably correct.
As to the privateness of the copy constructor, I didn't comment it, but
neither did I implement it: thats an idiom I use, to cause compiler
errors when someone tries to do something that they aren't meant to.
You could certainly make it public and implement it if you choose.
However, showing the error you get might be more useful...
Rob
signature.asc
Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)
On Tue, 2004-08-31 at 06:17 -0400, Doctor Bill wrote: Actually, this makes perfect sense. When you do SomeClass(), without using the new operator, you are telling the compiler to create this instance on the stack, and then when you do foo(SomeClass()) you are telling the compiler to pass this class by value. To do so requires creating a copy. No. You need to see the method signature to know if this is the case or not. As it happens the signature is void foo(SomeClass const ); This would not solve your problem. If you are trying to pass the class by value, a copy will still need to be made. And? there are two separate copy methods for classes: assignment operator and copy constructor. In this case the assignment operator is written and public, and the existing, working code has no copy constructor written. BTW. I would discourage all of these examples. Why? Because I firmly believe in using a smart pointer class, and making the actual constructors private. i.e. These two things are orthogonal. Smart pointers are good, but making the constructors private forces the class to be foreign storage only, which can be an unnecessary burden. ... If that was followed for all the code, then your original example would have been written: foo.create(Something.create()); eek. Any decent smart pointer class will let you do foo(SomeClass()); Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have aprivatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 14:27 +0100, Max Bowsher wrote: Robert Collins wrote: which is public, and should be usable. See: http://gcc.gnu.org/bugs.html#cxx_rvalbind I agree with you, but the C++ Standard and GCC 3.4 disagree with both of us. Eek. gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and whatever warning you are getting is probably correct. As to the privateness of the copy constructor, I didn't comment it, but neither did I implement it: thats an idiom I use, to cause compiler errors when someone tries to do something that they aren't meant to. Why is this something that isn't meant to happen? Because I hadn't written an explicit copy-constructor. You could certainly make it public and implement it if you choose. Do I need to implement it? AFAICS the implicit copy-constructor should be ok - am I wrong? the implicit one will work, but an explicit one would be good practice here IMO. Thats because we have a pointer (_operator) that isn't actually foreign storage, and explicitly copying the pointer, not the contents may make the intent clear. However, showing the error you get might be more useful... Thanks. Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification haveaprivatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 23:42 +0100, Max Bowsher wrote: Unless we add explicit copy-constructors to every single class, I'd rather just leave it out and let the compiler handle things implicitly? It seems cleaner to me. I think you'll find every class that has a destructor also has an explicit copy constructor assignment operator. That class certainly has an explicit assignment operator... being explicit on the copy constructor is consistent. Have you heard of the 'rule of 3' ? Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)
On Mon, 2004-08-30 at 18:33 +0100, Max Bowsher wrote:
I can't see why setup's PackageSpecification class has a private
copy-constructor.
Am I missing something?
erm. to only allow the class itself to create copies.
The reason why I am suddenly interested is that the C++ standard says that
this:
foo(SomeClass())
requires SomeClass's copy-constructor to be accessible (bizarre, no?) and
g++ 3.4 has decided to enforce this.
Even if that is in a method:
SomeClass *
SomeClass::funkyCopy() const
{
SomeClass *result(self);
}
?
So, unless I can make the
copy-constructor public (which I don't want to do if doing so risks other
problems), I need to rewrite all code like:
do_something(PackageSpecification(somename))
to:
PackageSpecification tmppkgspec(somename);
do_something(tmppkgspec);
which isn't very nice.
So we have code like that at the moment?
Rob
signature.asc
Description: This is a digitally signed message part
Re: More setup 2.427 problems.
On Sun, 2004-08-29 at 23:08 +0100, Max Bowsher wrote: Plus, although I'd put setup.exe into a folder entitled C:\cygcache and run it from there (and used it as the directory to download into), another folder, C:\cygwin, was created as well. It contains only 5 very small files in C:\cygwin\etc\setup. Hmm, I guess that's a bug. Setup shouldn't be creating those in download-only mode if the folder does not already exist. Nevertheless, they are only settings cache files - their purpose should be easily understandable from their names and contents. 5 to 1 odds the machine had had cygwin on it before, and there was a mount point details in the registry. Rob (Lurking) signature.asc Description: This is a digitally signed message part
Re: Seeking initial reactions: Moving setup from CVS to
On Fri, 2004-08-20 at 22:21 +0100, Max Bowsher wrote: Subversion is not a pre-condition for my work on setup - just something that would be extremely useful. I'm sure you can understand why contemplating moving lots of source files into subdirectories, whilst using cvs, does *not* fill me with joy. I guess it's time for me to look into the scripted-munging-of-RCS-files solution. Whats wrong with: cvs del old-file cvs add new-file ?? I'm asking this seriously - yes blame is cute, but its really not essential. Rob signature.asc Description: This is a digitally signed message part
Re: Seeking initial reactions: Moving setup from CVS to Subversion?
On Thu, 2004-08-19 at 00:42 +0100, Max Bowsher wrote: At some point in the medium-to-long-term future, I'd quite like to move the setup code from CVS to Subversion. Partly, that's because of all the little improvements subversion brings over cvs, but a notable concrete benefit subversion would bring is the ability to moves of files easily, without breaking up lines of history. This would be of great value, because setup would benefit from refactoring into one or more utility libraries, a core installation logic library, and one or more user interfaces - i.e. GUI and TUI. The ability to make subdirectories and move files into them, with ease, and without making it hard to access historical versions is key to making this feasible. If this is to proceed, I believe I'll need to contact the sourceware overseers and discuss whether there would be any obstacles to setting up subversion on sources.redhat.com . Right now, though, I'm just looking for initial reactions. I certainly wouldn't be proposing to start moving on this until after Subversion 1.1 is released, packaged for cygwin, and has had a little real world soak time - that would be about 2 months from now. I'm also not keen on this for several reasons: * subversion doesn't address the issues with merging distribution that made it difficult for folk with long-running patches to stay in sync * subversion appears to be a very fragile system (I'm working with quite a few projects that involve subversion, and breakage is common). * plus of course, that the rest of the project has shown no interest (at this point) in moving. Rob signature.asc Description: This is a digitally signed message part
maintainers wanted for:
setup.exe. squid. I recently went from a 20/80 split between two employers to full time with the one that was 80% and now find my self not using windows for 95% of the time. I'll carry on with bug support for setup until someone else steps up. Cheers, Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup preremove postremove
Preremove is to do things like removing cached rebased .dll's etc - things you can only do while the rest of your package is installed. postremove is to do cleanup that you cannot do while the rest of your package is installed. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [ITP] neon (A WebDAV library required by Subversion)
On Mon, 2004-05-03 at 21:56, Max Bowsher wrote: Reini Urban wrote: Max Bowsher schrieb: sdesc: An HTTP and WebDAV client library = neon === sdesc: A HTTP and WebDAV client library = libneon24 === sdesc: Runtime library component of Neon - an HTTP and WebDAV client library sdesc: Runtime library component of Neon - a HTTP and WebDAV client library I disagree, and so does the neon website. And you're both wrong. An Apple, A Car. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Two new categories created. Comment needed
On Thu, 2004-04-08 at 06:38, Harold L Hunt II wrote: [cue offended remark from Rob Collins after his last offended remark almost three weeks ago with still no action as far as I can tell, sorry Rob, but I wish you could be more honest with yourself about how much time you have]. I didn't offer to code anything up three weeks ago. If you want offended remarks, try this: Read what I wrote and don't troll. I offered to review patches - where are they? Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Two new categories created. Comment needed
On Thu, 2004-04-08 at 06:38, Harold L Hunt II wrote: A longer term solution would be a tag in setup.hint files that mark a package as removed, but this is insanely more complex. Erm, what precisely do you want here. Simply removing the package should be enough. Or are you looking for a 'replaces:' tag implementation? Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup.exe development stalled?
On Thu, 2004-03-25 at 23:29, Reini Urban wrote: Robert Collins schrieb: On Sat, 2004-03-13 at 08:07, Christopher Faylor wrote: At the very least, it would be nice to get out a new release which resized correctly. I know that the current implementation isn't perfect but I wonder if it is better than the alternative of having a new user a week sending in a suggestion that the browser should be resizeable. Why don't you just release the current snapshot? Lets put it to the floor. While I'm not happy with the current UI resulting from the resizability... if a simple majority of the package maintainers are, I'll release. There, hows that? Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup.exe development stalled?
On Fri, 2004-03-19 at 05:33, Harold L Hunt II wrote: Christopher Faylor wrote: It seems like development for setup.exe is sort of stalled. I agree completely. At the very least, it would be nice to get out a new release which resized correctly. I know that the current implementation isn't perfect but I wonder if it is better than the alternative of having a new user a week sending in a suggestion that the browser should be resizeable. Can we release setup.exe as is and maybe think about revitalizing development somehow? It would be nice if all of the things that the parser understands were actually understand by the rest of the program. I would like to see this very much and think it is a wise decision. In six days there has been zero discussion of this. Does that mean that setup.exe maintainership is up for grabs? If so, I've got things that I need to start doing with setup.exe, so I would be very interested in taking responsibility for setup.exe. I have the time for it now as well, and a project I am working on will really need setup.exe to be more robust and reliable (such as not blindly and silently unpacking files to mount points that do not point to physical disk locations). I'll start working on setup.exe next week and see how the maintainership question develops. The 6 days means that I'm in the middle of changing jobs. Starting April I have a new job with (hopefully) more personal time to do things like setup.exe. I don't consider the maintainership up for grabs - but please do start work on setup.exe, I'll happily review patches we have 3 folk with commit access who can commit. Assuming your patches are of high quality, there is no reason that you can't get commit rights in the future too. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
On Wed, 2004-02-25 at 07:04, Christopher Faylor wrote:
Wow. I can't believe I fell into this trap. I have been writing shell
scripts for a long long time and should know better.
Thanks for the heads up. I suspect that this accounts for some strange
installation problems.
Would it be worthwhile to just have setup.exe put /bin first in the path
when running these things? I know that the absolutely correct solution
is to use absolute path names in these scripts but people are going
to forget, so...
void
init_run_script ()
{
[..]
char old_path[_MAX_PATH];
GetEnvironmentVariable (PATH, old_path, sizeof (old_path));
SetEnvironmentVariable (PATH, backslash (cygpath (/bin) + ; +
cygpath (/usr/bin) + ;
+
old_path).cstr_oneuse());
[...]
Rob
--
GPG key available at: http://www.robertcollins.net/keys.txt.
signature.asc
Description: This is a digitally signed message part
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
On Wed, 2004-02-25 at 07:12, Igor Pechtchanski wrote: This might work, except that a) postinstall scripts on the whole are updated more often and more easily than setup.exe (i.e., this solution won't help people using the version of setup.exe they already have on their computer, so the scripts will still have to be fixed), Setup has done this the entire time I've been maintainer - I inherited it doing it. Igor, you've contributed to setup, I'm surprised you didn't look even a little into it. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
On Wed, 2004-02-25 at 07:21, Igor Pechtchanski wrote: Rob, However, the postinstall scripts did fail to run correctly (for some reason or another), and I just assumed that this was the reason. Even if it isn't, the scripts still needs to be fixed, IMO. Ok, so the question is why didn't they run? Was the path wrong for the script (note it will be the windows PATH, perhaps the startup logic getting a cygwin PATH from that had a hernia, or some problem before /etc/password etc was together... But we don't need to 'fix' all scripts IMO. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
On Wed, 2004-02-25 at 07:39, Harold L Hunt II wrote: I'm updating the xfig setup.hint files right now. I am also fixing the longstanding issue of depending upon ghostscript instead of 'ghostscript-x11 ghostscript-base'. This has caused numerous compliants about being unable to export figures correctly from xfig. if ghostscript-x11 depends on ghostscript-base, and you don't explicity call stuff in ghostscript-base, then you should not list ghostscript-base. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
On Wed, 2004-02-25 at 07:49, Harold L Hunt II wrote: I suggest that it does make sense to put in an explicit dependency on some such packages, though perhaps not all such packages, because if a user already has ghostscript-x11 and ghostscript-base installed, then manually uninstalls ghostscript-base, then selects xfig, I believe that ghostscript-base will not be reselected. Thats wrong. Setup traverses the dependency tree. Rather than field bug reports, I would prefer to just prevent that from happening. On the other hand, if setup.exe always does a full recalculation of dependecy trees when selecting a new package, then this will never be a problem and I can indeed remove ghostscript-base from the dependency list. It does. Of course, I am lazy, so I have not tested this case recently. http://www.cygwin.com/setup.html A package can rely on multiple other packages. Hierarchical dependencies should work correctly, however, it is best to always include specific dependencies, i.e. don't drop 'bar' from your dependency list if your package requires it, even if you are including 'foo' which relies on 'bar'. Conversely, do not include package dependencies of dependent packages in your dependency list. If you think that another package has an incorrect dependency list, send email to cygwin-apps noting that fact. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: a script to remove empty directories
On Fri, 2004-02-20 at 01:56, Andreas Seidl wrote: Igor Pechtchanski wrote: Feel free to send a patch for this. ;-) Igor I have written the following script, which is as good as I can do at the moment. Oh . I'm sorry, I replied to the wrong thread with my previous email about this being uselss Again - I'm sorry. Rob (goes off to get coffee...) -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: a script to remove empty directories
On Fri, 2004-02-20 at 01:56, Andreas Seidl wrote: Igor Pechtchanski wrote: Andreas, Feel free to send a patch for this. ;-) Igor I have written the following script, which is as good as I can do at the moment. And is utterly useless. Cygwin setup is written in C/C++. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Cron cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0]
On Wed, 2004-02-04 at 05:26, Christopher Faylor wrote: - Forwarded message from Cron Daemon - From: root (Cron Daemon) Subject: Cron cgf cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0 Date: 3 Feb 2004 18:20:06 - upset: release/xemacs/xemacs-emacs-common/setup.hint:5: unknown key 'conflicts: emacs' - End forwarded message - Please don't invent setup.hint keys... FWIW it's a valid setup.ini key. And has been for quite some time. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: upset and the setup.exe package server
On Thu, 2003-12-11 at 16:30, Joshua Daniel Franklin wrote: Actually, after looking things over, I think that cygwin-apps would be the best place to put this. Am I cleared for messing with the cygwin-apps htdocs as well as the Cygwin ones, or are they separate projects? I got the htdocs from CVS fine, but I don't want to start adding pages without someone saying it's OK. I'll still be sure to note that upset is provided as-is. separate projects - but please go ahead. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: upset and the setup.exe package server
On Tue, 2003-12-09 at 17:48, Joshua Daniel Franklin wrote: I do link to http://cygwin.com/setup.html which truly documents the setup.ini and setup.hint files. Maybe that page would be a good place to add some comments about upset? Don't forget http://sources.redhat.com/projects/cygwin-apps/setup.html Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
RE: non-setup information in setup.hint (was Re: Maintainers/Pack ages List, 2003-11-22)
I'm not sure why this is non-setup information. Both binary only (no source: entry for a package), and Maintainer are setup.ini fields. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
RE: non-setup information in setup.hint (was Re: Maintainers/Pack ages List, 2003-11-22)
On Wed, 2003-11-26 at 10:32, Daniel Reed wrote: On 2003-11-25T20:53+1100, Robert Collins wrote: ) I'm not sure why this is non-setup information. Both binary only (no ) source: entry for a package), and Maintainer are setup.ini fields. Were you suggesting using Maintainer: and relying on setup to ignore it? (Neither http://sources.redhat.com/cygwin-apps/setup-2.249.2.ini.html nor http://sources.redhat.com/cygwin-apps/setup.html seem to define a Maintainer: field.) See inilex.l and iniparse.y. Maintainer is fully parsed, in the manner that it appears in debian Sources list files. The rest does make sense as not-for-setup.ini stuff. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: non-setup information in setup.hint (was Re: Maintainers/Pack ages List, 2003-11-22)
On Wed, 2003-11-26 at 11:25, Christopher Faylor wrote: I'm not sure why Maintainer: makes sense as a for-setup.ini field given our stated policies. It doesn't have to go into setup.ini - I was simply stating my confusion about inventing a new syntax, when one already exists. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Maintainers/Packages List, 2003-11-22
On Tue, 2003-11-25 at 07:48, Christopher Faylor wrote: cgf (who's madly trying to think up some scheme to make the gold stars actually worth something) Whats the exchange rate :}. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: still broken squid
On Mon, 2003-11-17 at 18:39, [EMAIL PROTECTED] wrote: Hello, it appears that the broken squid problem still persists (running the latest snapshot 11/11/2003 dll) Yep. It's on my TODO. Don't ask how long that is :}. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Setup: more intuitive resizing controls + some dialogs
On Sun, 2003-11-02 at 13:01, Igor Pechtchanski wrote: On Sun, 2 Nov 2003, Robert Collins wrote: Ah, I see. We must have different definitions of centered. I view CP_MIDDLE as same size but centered around the new position, which will require the left and right edges to be adjusted evenly. You seem to be thinking of centered as stretch proportionally to the position in the dialog... In other words, in the above example the control should end up at 30,49 using my definition (keeping its size at 20). I'm not convinced it's a bug. We could, of course, add other positioning controls (e.g., CP_SMARTSTRETCH) that do what you want. Ok, turned into CP_CENTERED. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: AW: [Patch] Resizing fixes
On Sun, 2003-11-02 at 03:25, Ralf Habacker wrote: The first one is to split the list into two parts: a category window on the left side and a package list on the right (like yast on suse linux) and second a search field to search for a specific package. re: splitting - that sounds possible. I'd prefer to retain the existing screen layout for smaller screen real estate PC's. The chooser probably needs tweaking to allow two instances, and for a choice in the categories instance to switch the content of the right instance. (Or just the position). re: a search button. To do this, I suggest a pop up chooser with the search results, this needs the same multi-instance redesign of the chooser. 2. the package windows does not need a horizontal scrollbar, because the package informations are printed on the window bottom when selecting a package, this reduces the needing scrolling operations to read the package info. In short: The user does see more information at one time. This doesn't follow from what you described above. I presume it's a yast thing? No objection here. (1) this icon could be toggled through install (with choosing the requested releases), uninstall, reinstall, upgrade,... (2) I don't think that it makes sense to add a install, uninstall button for each category. Makes it sense to install *all* databases or *all* editors ? I don't think so. Upgrading all packages in this category makes more sense, i think. it does make sense to install or uninstall everything in some sections. I.e. Base. Or Development. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Setup: more intuitive resizing controls + some dialogs
On Sat, 2003-11-01 at 14:35, Igor Pechtchanski wrote: As promised. Igor == ChangeLog: 2003-10-31 Igor Pechtchanski [EMAIL PROTECTED] Applied. I think there's a bug in the MIDDLE enum handling though. I've factored the code to be less redundant - please check... There are still a few quirks - like the mirror selection page. Lastly, do the vertical coords need adjusting to client coord ? Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
On Sat, 2003-11-01 at 12:16, Ralf Habacker wrote: Rob I need more time to think about what you have written and how to start with which class, I have take some time to inspect how it could be go and have build a testcase to see what kind of api is needed. Please note that I am concentrated only to get a command line version initial running, so I've removed the not needed gui stuff. Currently I can't send in a patch for this, because I have splitted the relating engine files into subdir and build a static library to allow file including checks, although the binariy and sources could be downloaded here: binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe. source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2 Sounds like you've gone too far too fast. I don't have the time to review a non-delta set of changes. Particularly ones that throw away a lot of code (the gui) that -must- be retained. Any comments ? Yes. I sketched out a fairly minimal development path to generate a commandline setup that doesn't involve forking the engine code. You haven't commented on the approach, rather you appear to have just ignored it completely. Shrug. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Patch] Resizing fixes
On Fri, 2003-10-31 at 23:33, Frank Richter wrote: This patch now properly deals with minimizing the window - before, some sizes/positions were slightly off when the window was minimized and restored. It also constraints the size of the property sheet, it now can't get smaller than it's initial size. APplied. Please submit patches with diff -up always - they are much easier to read, and more robust at applying to altered source. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Patch] Improved error message when selecting directory fails
On Fri, 2003-10-31 at 23:36, Frank Richter wrote: Now, the last error code is evaluated and an appropriate message is displayed. There's also a choice to 'Retry', 'Ignore' the error or 'Abort' the directory change. The idea is that under circumstances the user may be able to fix the cause of the problem (e.g. by connecting to a remote share) and then can just go on with the setup. Applied. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Setup: more intuitive resizing controls + some dialogs
On Sun, 2003-11-02 at 07:20, Igor Pechtchanski wrote: On Sat, 1 Nov 2003, Robert Collins wrote: On Sat, 2003-11-01 at 14:35, Igor Pechtchanski wrote: As promised. Igor == ChangeLog: 2003-10-31 Igor Pechtchanski [EMAIL PROTECTED] Applied. I think there's a bug in the MIDDLE enum handling though. I've factored the code to be less redundant - please check... Hmm, if there's a bug, I don't see quite what it is. Would you mind elaborating? the stretch adjustment moves both left and right by delta/2. If we had a window 0,39, with a control at 10,29, and we resize the window to 0,79 - a delta of 40, we'd want the control to end up at 20,59 - that is the left adjusted by delta/4 and the right by 3/4 delta. Details, please? When I resize it vertically, the url field label stays put. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: let me be the first...
On Sun, 2003-11-02 at 04:16, Christopher Faylor wrote: I'm having a hard time with setup.exe. Every time I run it, I have to resize the Packages to Install screen (or whatever it is called). Couldn't you just make the screen bigger or, at the very least, remember the size I chose for the window so that I don't have to resize it every @(# time??? This is actually easy enough: add a UserSetting, as for example local_dir.cc has, to save the screen co-ordinates from the surrounding wizard window., and to load them. Then in main restore the loaded co-ordinates. IOW, the framework is there to do that easily. If you want people to use this product, you should make sure that it is intuitive and easy to use. It can't be that difficult to correct this *bug* in setup.exe. cgf P.S. But seriously, I love the ability to resize this screen. This is a ten gold star achievement. Likewise. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: archive.progeny.com gone
On Wed, 2003-10-29 at 06:26, Christopher Faylor wrote: I guess archive.progeny.com was sick of being the first alphabetically in our mirror list. They are no longer mirroring cygwin and I've removed them from the mirrors.txt file. They should be gone when the next mirror list refresh runs today. Get ready for the deluge on [EMAIL PROTECTED] Setup complains it cannot find setup.X. Nothing we can do about it (other than a really ugly hack to check archive.progeny.com the same way we do sources.redhat.com.) A more clean check would be to move those sites into the sites master list... PTC. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
RE: [PATCH] setup - help and local dir command lineoptionswasRe: Setup Command Line Options
On Tue, 2003-10-28 at 04:12, Ralf Habacker wrote: Not quite: I'm not in the business of splitting up patches and adjusting changelogs - could you please provide: The patch for main.cc and localdir.cc The updated changelog Here is it. Applied. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Patch] Resizeable main window
On Fri, 2003-10-17 at 06:59, Frank Richter wrote:
On 16.10.2003 22:29, Robert Collins wrote:
Before further review, I'd like you to correct
such abuses of C++.
Done.
Please include new files in the diff. (You can use diff -Nup /dev/null
newfile.cc maindiff) Saves me time guessing whether those files are
all attached or not.
This looks good, but:
- The header in the chooser doesn't resize for me - does your framework
support that?
- We need some testing of older os's.
code wise, please don't add more sizing tweaks other than the chooser's
header until we get this in - i.e. keep it focused.
- I don't like the static struct _PropSheetData idiom. How about class
PropSheetData { ... static PropSheetData Instance();}
PropSheetData
PropSheetData::Instance()
{
static PropSheetData TheInstance;
return TheInstance;
}
Cheers,
Rob
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
signature.asc
Description: This is a digitally signed message part
Re: [Fwd: Re: [Patch] Resizeable main window]
On Fri, 2003-10-17 at 07:19, Frank Richter wrote: Original Message Subject: Re: [Patch] Resizeable main window Date: Thu, 16 Oct 2003 23:19:05 +0200 From: Frank Richter [EMAIL PROTECTED] To: Robb, Sam [EMAIL PROTECTED] References: [EMAIL PROTECTED] On 16.10.2003 23:10, Robb, Sam wrote: The header on the chooser isn't resized along with the chooser, though. However, if you scroll horizontally or drag one of the columns to resize, the header appears correctly. Not for me. The header stays fixed at the original width, truncating any resized column titles. I need to know that this can be addressed before approving the patch - if your approach isn't compatible with addressing this... Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: AW: [PATCH] setup - help and local dir command line options wasRe: Setup Command Line Options
Oh, and please resubmit the patch with the correction I requested.. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: PATCH: Save/load proxy settings in setup.exe
On Thu, 2003-10-23 at 23:27, Jerry D. Hedden wrote: On Thu, 2003-10-23 at 22:55, Jerry D. Hedden wrote: One of the items on the TODO list for setup.exe is to save and load proxy settings so the user doesn't have to keep entering them. Below is a small patch to ConnectionSetting.cc to do just that: --- From: [EMAIL PROTECTED] Please supply: - the patch as an attachment, created using -up on diff. Attached. Thanks, applied. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: AW: [PATCH] setup - help and local dir command line options wasRe: Setup Command Line Options
On Sat, 2003-10-25 at 22:23, Ralf Habacker wrote: This is in the wrong place: LocalDirSetting::load is the right method to query the option from. While thinking about this a while more, I recognized that there is some more basic work necessary how to design the command line interface. Are there any other requests or hints about the design ? I've roughed stuff out here before, I think. Anywhere, here goes a quick brain dump. For me there is currently one major question. Is it possible to print message on stdout/stderr from a gui application ? No. To show the help to the user, setup needs to show a dialog with the help content in it. To do that, either: 1) provide a ostringstream to the ParameterUsage() call. or 2) iterate through optionsInSet() and do your own formatting. (see the source for OptionSet::ParameterUsage for an example of how to do it). Then put whatever you've generated into a dialog. If not than the first step seems to me really to split the gui from the core, so that a console application could be build. Has anyone done some analysis, where the cut could be done ? Yes. This is a much bigger project than that needed to show the help to the user. A personal note: I will take some time for this because this is a need for further kde releases, so I probably will be able to help with the design, implementing some functions and making an initial design document about the command line design works, but there is much more work to do. At all I see the following tasks: 1. analyse how to seperate the gui from the engine (the core) and the helper classes/code I'm pretty simple on this: we need an engine that has no UI, provides * A single thread interface. having the UI needing to be aware of engine thread status would be seriously complex. Instead, the engine will be communicated with via a single thread, and may create it's on worker threads for async activity. No engine calls will block - they must return immediately. * Provides callbacks to the UI on progress. calls that haven't completed when the engine returns, will signal completion via a later callback. We can use one of: - async completion tokens. - callback wrappers (i.e. via a signals and slots library) - standard windows messages I don't have a particular preference, but I've listed those in likely order of difficulty (for migration from the current code base) - and we should only use one approach. If we want to use windows messages, I suspect we want to wrap the engine in an adapter - as the command line tool won't have a message loop. * never throws exceptions: all errors must be handled in the engine, and propogated to the UI via the callback mechanism. (We need a callback for engine termination.) The UI needs to be able to: * query the engine for the available options * hand user details into the engine * retrieve structured data (ie. the list of sites) * attempt to action a given stage of the engine. * display progress of long running tasks. in terms of code separation, I wouldn't rush to put everything in different dirs - see inilintmain.cc for the beginning of a command line tool (one just to lint the ini file). A solid, minimal waste of time approach would be to: 1 - define the engine API. in doing this, the -core- is: initialise (returns an instance of something) get option help terminate and initialise get instance for the first stage. perform an action on that stage ... repeat terminate note that the details for the actions can wait - it's only the outline that is needed initially. callback actions like moving to the download/downloadinstall/install from the chooser will have an api dependent on the choice of callback mechanism. Also note that the engine cannot include -any- GUI headers. 2 - once the engine api is defined, work on the callback mechanism. minimally it needs to support: * polling for events (i.e. from the windows idle event in the main thread) * waiting for events (i.e. from a timer-less event loop in a command line app) * notification of events (i.e. a % point completed, a change in download time/expected completion time, package installation progress etc). a small worked example: during downloading, the download thread should store status detail in the engine. When the window idle thread comes around, it polls for events. The engine then notifies if something has changed. The notification might be a status change in an async completion token (in which case we'd check those after the poll), a callback to a slot (in which case it'd take effect immediately). 3 - introduce the engine to main.cc. Move the loggin calls into the engine. Other than that, all it needs to do is be initialised and terminated. 4 - with the engine and callback interfaces in place, start a setup-cmdline project within the current framework (see the inilint target in Makefile.am). - start with what main.cc does. assign each task to either
Re: [Patch] Resizeable main window
I've committed Franks code - thanks Frank. I decided not to wait for the win98 tests, as it's been 2 weeks, which is IMO enough time for bugs to surface, from folk interested in this. Gary, I know we spent mucho time heading towards integration of your patch, I'm sorry that some of that effort was wasted. I'm sure you have a number of non resize related patches outstanding (ironically, the reason I had issues with your patch)... if you'd like to see those in setup, I'm more than happy to review them as usual. I've uploaded a new setup. For now, I'm not going to announce this on cygwin@ - only folk following the discussion here need to be involved until we're happy with the visual appearance. I'm not unhappy with it, but Igor was indicating a number of tweaks, and Gary had some thoughts. I'm sure that there will be a number of requests from the peanut gallery relating to this as well ;) I don't have a particular appearance in mind, so generate patches, lets get some feedback, and when it's cooked, we can do another release of setup. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Patch] Resizeable main window
On Mon, 2003-10-27 at 07:10, Robert Collins wrote: I've uploaded a new setup. For now, I'm not going to announce this on ... snapshot. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
On Mon, 2003-10-27 at 04:33, Ralf Habacker wrote: Rob, I've roughed stuff out here before, I think. Anywhere, here goes a quick brain dump. I need more time to think about what you have written and how to start with which class, but let me ask one question now, perhaps you can fix this: Have you tried to compile the inilint example in the last time ? I have to add so many additional files because of dependencies and the last one 'threebar.o' one introduce a gui class, so the example could not be build as console application :-( Right. inilint was the beginning of a new program - not complete, and slightly bitrotted. However, it could well be a good starting point for using the engine. Adding a gui component is obviously not the right thing to do. The point about inilint is to see how it's integrated in to the build system. I'd rather not be moving files around until after the functionality split is complete. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] setup - help and local dir command line options was Re: Setup Command Line Options
On Sat, 2003-10-25 at 10:43, Ralf Habacker wrote: Below there are two patches: 1. A patch implementing a help option, it prints it output to the setup.log (main.cc) Approved. 2. Additional a patch to allow setting the local dir from the commandline. (localdir.cc) This is in the wrong place: LocalDirSetting::load is the right method to query the option from. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
[Fwd: Re: PATCH: Save/load proxy settings in setup.exe]
Max, could you please commit this.
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---BeginMessage---
On Thu, 2003-10-23 at 22:55, Jerry D. Hedden wrote:
One of the items on the TODO list for setup.exe is to save and load
proxy settings so the user doesn't have to keep entering them.
Below is a small patch to ConnectionSetting.cc to do just that:
--- From: [EMAIL PROTECTED]
Please supply:
- the patch as an attachment, created using -up on diff.
Attached.
- A changelog.
2003-10-23 Jerry D. Hedden [EMAIL PROTECTED]
* ConnectionSetting.cc (ConnectionSetting::load): Load proxy
settings.
(ConnectionSetting::save): Save proxy settings.
=
Jerry D. Hedden
If you're not having fun, then you're not doing it right!
--- setup-0/ConnectionSetting.cc2003-07-30 05:04:27.0 -0400
+++ setup/ConnectionSetting.cc 2003-10-23 09:15:28.297445000 -0400
@@ -36,9 +36,15 @@ ConnectionSetting::load()
{
char localdir[1000];
char *fg_ret = f-gets (localdir, 1000);
- delete f;
if (fg_ret)
net_method = typeFromString(fg_ret);
+ fg_ret = f-gets (localdir, 1000);
+ if (fg_ret)
+net_proxy_host = strdup(fg_ret);
+ fg_ret = f-gets (localdir, 1000);
+ if (fg_ret)
+net_proxy_port = atoi(fg_ret);
+ delete f;
}
inited = 1;
}
@@ -46,6 +52,7 @@ ConnectionSetting::load()
void
ConnectionSetting::save()
{
+ char port_str[20];
io_stream *f = UserSettings::Instance().settingFileForSave(last-connection);
if (f)
@@ -59,7 +66,9 @@ ConnectionSetting::save()
break;
case IDC_NET_PROXY:
f-write(Proxy\n,6);
-// TODO: also write the proxy and port, and then parse them in load.
+f-write(net_proxy_host,strlen(net_proxy_host));
+sprintf(port_str, \n%d\n, net_proxy_port);
+f-write(port_str,strlen(port_str));
break;
default:
break;
---End Message---
signature.asc
Description: This is a digitally signed message part
Re: setup.exe don't stops memory leak?
On Thu, 2003-10-09 at 06:53, Gerrit P. Haase wrote: Hallo, That was with the setup.exe version I checked out today from mirrors.rcn.net. Which could be any version. What was the version number? Also, your best bet to fix this is to build a debug version and break into in when this happens. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
RE: [forwarded email: cygwin mirrors and installation]
On Tue, 2003-10-07 at 13:02, Gary R. Van Sickle wrote: You'll have to forgive my ignorance here, but is there some way to query ftp/http servers for how much load they're under? Not as a standard. Thinking out loud, what we roughly want is: -users can choose any mirror explicitly. -on the first run, setup lists the servers in their 1/3 of the world (say europe, asia, americas) and randomly chooses one from there, letting them alter the choice, or click something to see the entire list. -when we implement this, setup treats it as a watershed event on existing installs, and displays a little explanation and consider 'first run' to be occuring. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Setup disabling of nonexistent virus scanners
On Tue, 2003-10-07 at 11:32, Gary R. Van Sickle wrote: Hmmm, yeah, I'll look at this. I wonder why I don't get this and (I assume) others don't Incorrect const clause on wantsActivation in the base class lead to inconsistent method signatures. I fixed this this morning, but have been rushed - so no announcement. This affected the display of the 'root' dialog too. However, there is a new setup.exe as of ~10 hours ago. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
RE: Setup disabling of nonexistent virus scanners
On Tue, 2003-10-07 at 21:33, Gary R. Van Sickle wrote:
I don't understand. In proppage.{h,cc} (the base class) and in any overrides
(i.e. root and AntiVirus) both I and CVS have:
virtual bool wantsActivation() const [etc...]
CVS was missing the const. See the most recent commit to proppage.h.
Rob
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
signature.asc
Description: This is a digitally signed message part
Re: [setup PATCH] Rework do_download [next_dialog removal (2b)]
On Tue, 2003-09-30 at 21:49, Max Bowsher wrote: Robert Collins wrote: On Thu, 2003-07-31 at 08:16, Max Bowsher wrote: And another... This seems more complex than the previous code. You're moving window specific code from the specific class into the generic threebar class. This doesn't seem right to me. I think the code I moved is better classified as program flow logic. threebar.cc is already our main controller of program flow once the initial few pages of settings are complete. At the moment, as individual window is handling decisions on what to display next - *that* doesn't seem right to me - it's exactly what wantsActivation was introduced to avoid. I can agree that threebar.cc isn't the most elegant place to be handling program flow, but that fact doesn't reduce the merits of tidying and collecting program flow logic into a central location. Well program flow is basically an application script. Moving anything more into threebar would be a mistake IMO. Some screens are bundled together: the script should see them as a single entity. Other screens are independent and the script needs to know to tie them together and provide ordering. I have no burning desire to remove next_dialog the wrong way. wantsActivation was introduced to avoid centralised decisions AND to avoid screen awareness of the sequence of unrelated screens. It's achieved that. This particular change is simply shifting the awareness of the program flow from a generic core component to a generic GUI component. Thats not a win. Vague handwaving description follows. Create a class GUIController. Give it a method such as sheetid nextCommand(currentSheetID) in nextCommand, put all the switching and conditional logic your heart desires. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Rework do_download [next_dialog removal (2b)]
On Thu, 2003-07-31 at 08:16, Max Bowsher wrote: And another... This seems more complex than the previous code. You're moving window specific code from the specific class into the generic threebar class. This doesn't seem right to me. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: package download stats?
On Fri, 2003-09-19 at 01:11, Christopher Faylor wrote: That's kind of what I was thinking. I could generate a cgi script to run, if necessary but obviously it would need some kind of authentication to avoid abuse. Is there something like this out there somewhere? popularity-contest does something similar in the debian world - anonymous stats on package use... Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: package download stats?
On Fri, 2003-09-19 at 03:18, Christopher Faylor wrote: I'm all for adding this to setup but we'll have to wait for Robert to come online to see his take on this. I'm not all that interested, though I will review patches for impact on setup. Clean design etc etc needed. It doesn't feel like setup is a good fit: 1) setup isn't the only thing installing cygwin apps's. 2) CD, disconnected installs, rsync copies of mirrors will all throw this out. however, the concepts used by popularity contest, - an explicit package to activate the behaviour, anonymous stats on what packages are installed (and logging more detail to enhance a hypothetical cygwin populatiry contest makes a lot of sense for setup). And there is definately a privacy issue - what about non public packages. They would show up ... Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: broken squid
On Fri, 2003-09-19 at 06:10, [EMAIL PROTECTED] wrote: Just ran and update of my cygwin tree, it appears that squid has stopped working. note that i have already upped my file descriptor limit. thanks. jake This is possibly a cygwin1.5 thing, I'm planning a new build of squid this weekend, as it happens. Please try one of chris' nightly snapshots, as there have been a number of small errata in 1.5.x... Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Preremove section in http://cygwin.com/setup.html
On Wed, 2003-09-17 at 04:16, Igor Pechtchanski wrote: Ping! Pong. You had actions listed in your email, that you haven't come back to me with their results.. Rob On Thu, 10 Jul 2003, Igor Pechtchanski wrote: Rob, Replies inline. On 10 Jul 2003, Robert Collins wrote: Well, we haven't set a policy on the number of postinstall scripts. I'd really prefer one package == one script. It feels cleaner to me that way. It's a general rule of thumb, but it's just a policy, not an implementation limitation. It might be cleaner sometimes to create multiple postinstall scripts to clearly separate the functionality -- see base-files, for example. Also, it's not guaranteed that all your depended-upon scripts will run when a cycle is present. That is, if foo depends on bar, and bar on foo, only one of the two will have the scripts run first. Might be an idea to mention that (and the 'normal' approach of breaking the common stuff into a third package both depend on). True. I'll change that section. Pre remove scripts are limited to -one- per package. Either .sh or .bat. If setup supports both at once, it's an accident and is not guaranteed to remain. Again, for consistency, all scripts should be one per package. Pre-remove scripts are invoked using try_run_script(), which will execute *both* .sh and .bat if present. Other than those issues, it looks good to me. Rob Ok, I'm attaching another iteration. Incidentally, what's the official spelling of postinstall and preremove? Is it with a hyphen, with a space, or as one word? Igor On Thu, 2003-07-10 at 12:25, Igor Pechtchanski wrote: On Sat, 24 May 2003, Sergey Okhapkin wrote: Actually, all us package maintainers ought to do a better job including pre-remove scripts in addition to post-install scripts, that would clean up anything created by the postinstaller. Yep -- setup supports this -- but most maintainers (I'm guilty here...) don't bother: I never heard about pre-remove support in setup, http://cygwin.com/setup.html has nothing about. Attached is a patch to http://cygwin.com/setup.html that talks about preremove scripts and brings the postinstall section up to date. I'm targeting it here rather than to the main cygwin list because IMO it is of more interest to this audience, having to do with package maintenance and setup.exe. I can also check this in if it's approved. Igor -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: new package proposal : CLISP
On Sun, 2003-09-14 at 05:10, Charles Wilson wrote: I think the setup.hint format allows build-requires, but I'm not sure if setup.exe supports them -- or if it should. What if I want to simply download a source package to look at it, but not build it? Yep. The parser handles build-depends. And the GUI doesn't allow you to say 'get the build-depends'. I agree that setup not download the build depends unless requested. And even if it's not requested, having the build depends is, and always should be optional. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Work with gcc-3.3.1
On Tue, 2003-08-19 at 07:17, Max Bowsher wrote: +2003-08-18 Max Bowsher [EMAIL PROTECTED] + + * win32.h: Undefine NOMINMAX before defining it, as libstdc++-v3 3.3.1 + defines NOMINMAX itself. Does it define it the same way? I'd rather we did #ifndef NOMINMAX #define NOMINMAX #endif Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Setup: clarify confusing antivirus log message
On Sun, 2003-08-17 at 12:16, Igor Pechtchanski wrote: I didn't think we needed this either, but there were a few people who did read the logs (without much more knowledge of setup). Frankly, some of the setup-related questions on the list result in a request to post the log, and apparently some people do peek into them (after searching the archives - whoohoo, somebody *is* doing it!). An example is http://cygwin.com/ml/cygwin/2003-08/msg00761.html. Thats just you adding to the confusion :}. So I decided that since we do write a reasonably verbose message to the log, we should clarify it. Otherwise, let's make it cryptic enough not to arouse people's suspicitions. Does the above make sense? Not really. Its a detailed message about internal operations. Lets leave it at that. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Setup: clarify confusing antivirus log message
On Fri, 2003-08-15 at 02:41, Igor Pechtchanski wrote: 'Nuff said. I don't think we need this. The log file is -not- readable without knowledge of setup. Any assumption folk draw from it need 'expert' review anyway. In short, this change is for folk that shouldn't be reading the log anyway. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Subscribers only...
On Mon, 2003-08-11 at 19:13, Morrison, John wrote: Hi all, I tried to send an email to -apps this morning from one of my home accounts, it bounced because that account is not actually subscribed. I actually have one subscribed account which .forwards to others. Would it be possible (all meaness aside ;) to have one subscribed address for recieving email and one (or more) addresses for sending to the list? Yes, check the email you where sent when you subscribed, or the list info page. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Bug in lynx setup.hint? (was: Re: cygcrypto-0.9.7.dll)
On Tue, 2003-08-12 at 08:39, Igor Pechtchanski wrote: On Mon, 11 Aug 2003, Igor Pechtchanski wrote: Ahem, actually, reading the setup sources (inilex.l), it looks like the colons *are* required. Rob, it's your code, care to comment? Igor P.S. This belongs on the cygwin-apps list, IMO. Oops, sorry, Rob, just read your reply on the Cygwin list... Well, to make this cygwin-apps thread at least marginally useful, here's a patch to htdocs/setup.html that clears this confusion -- permission to apply? Lets wait for Chris to get back. Remember that .hint files are preprocessed to create the .ini - I don't know the current status of the preprocessor - all I was commenting on was the requirement in the .ini file... Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup.hint question
On Thu, 2003-08-07 at 01:39, Igor Pechtchanski wrote: As far as I understand, no harm (except for some extraneous downloads) will be done if you list both as dependences. This is much less worrisome than a missing dependence, so I'd say go ahead and list both. When 1.6.7-2 becomes curr, you can throw out the libncurses6 dependence. Igor setup.ini can actually list the correct dependency against the correct version of cmake. I don't know if setup.hint has that facility though. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup.exe: always creating a /usr/src directory?
On Sun, 2003-08-03 at 03:19, Jari Aalto+list.cygwin-apps wrote: I have noticed interesting thing with 2.340.2.5 setup.exe setup needs to be extended in it's mkdir logic to understand new-form symlinks, and to honour them. currently it doesn't. However, it's recommended to use a mount point, not a symlink anyway, and that should work correctly. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Use vector instead of array to storePropertyPage pointer list.
On Sat, 2003-08-02 at 21:57, Max Bowsher wrote: +2003-08-02 Gary R. Van Sickle [EMAIL PROTECTED] + + * propsheet.cc (Copyright): Update copyright dates. + (PropSheet::PropSheet): Remove NumPropPages initialization. + (PropSheet::CreatePages): Use PropertyPages.size() instead of + NumPropPages. + (PropSheet::Create): Ditto. + (PropSheet::AddPage): Change to use new PropertyPages std::vector. + * propsheet.h (Copyright): Update copyright dates. + (File Scope): Include vector. + (PropSheet::PropertyPages): Change from array to vector. + (PropSheet::NumPropPages): Remove. rather than PAGE_CONTAINER, please call the typedef PageContainer. Other than that, it's approved. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Fix ChangeLog
On Sat, 2003-08-02 at 21:01, Max Bowsher wrote: 2003-08-02 Max Bowsher [EMAIL PROTECTED] * ChangeLog: Fix broken line-wrapping throughout. Remove Ran automake from 2003-07-26 entry - since there are no generated files stored in cvs, this was neither a change, nor needed to be logged. Patch not sent, since it is long and boring, and the ChangeLog entry says it all. I don't see the point in this. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
RE: [setup PATCH] Add icon to title bar
On Sat, 2003-08-02 at 20:30, Gary R. Van Sickle wrote: See what you've been missing? Have you even looked at my not-entirely-uncool page dedicated to Cygwin setup? There's an old friend there waiting to greet you ;-)! http://home.att.net/~g.r.vansickle/cygwin/setup/ Time is the key - I'm chronically short on time these days. If you'd had a bunch of separate patches, I'd likely have made time :}. Anyway, it's great what Max is doing... Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Fix ChangeLog
On Mon, 2003-08-04 at 02:22, Max Bowsher wrote: Robert Collins wrote: On Sat, 2003-08-02 at 21:01, Max Bowsher wrote: 2003-08-02 Max Bowsher [EMAIL PROTECTED] * ChangeLog: Fix broken line-wrapping throughout. Remove Ran automake from 2003-07-26 entry - since there are no generated files stored in cvs, this was neither a change, nor needed to be logged. Patch not sent, since it is long and boring, and the ChangeLog entry says it all. I don't see the point in this. I like things tidy and accurate. I've already got the changes in a working copy ready to commit. Any actual reason not to? Because 1) that ran automake line is there for a reason. (check the bz2lib and zlib directories), and 2) I don't see whats untidy. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Fix ChangeLog
On Mon, 2003-08-04 at 07:04, Max Bowsher wrote: Because 1) that ran automake line is there for a reason. (check the bz2lib and zlib directories), Aha. What about this then: * bz2lib/: Ran automake. * zlib/: Ditto. Thus preventing the misunderstanding I just demonstrated. Hmm, ok. I'm not entirely happy about altering the ChangeLog post fact though. and 2) I don't see whats untidy. The broken line wrapping. (There are a number of lines wrapped to slightly over 80 columns.) Ok, go ahead. Be warned though, you'll need to be used to doing this, as I use an rxvt term when editing the ChangeLog - 80 chars doesn't particularly interest me. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Preremove section in http://cygwin.com/setup.html
On Fri, 2003-07-11 at 01:05, Igor Pechtchanski wrote: Rob, Replies inline. On 10 Jul 2003, Robert Collins wrote: Well, we haven't set a policy on the number of postinstall scripts. I'd really prefer one package == one script. It feels cleaner to me that way. It's a general rule of thumb, but it's just a policy, not an implementation limitation. It might be cleaner sometimes to create multiple postinstall scripts to clearly separate the functionality -- see base-files, for example. I suspect I forgot to reply.. so here goes. It may be cleaner - and if so, those other scripts can live elsewhere - i.e. /usr/libexec/base-files/helper-scipts/... It's certainly not cleaner for setup. SO, edict time: setup may not in the future support multiple scripts per package, and our documentation therefore /must not/ assume that that is ok. Pre remove scripts are limited to -one- per package. Either .sh or .bat. If setup supports both at once, it's an accident and is not guaranteed to remain. Again, for consistency, all scripts should be one per package. Pre-remove scripts are invoked using try_run_script(), which will execute *both* .sh and .bat if present. Again, it does != it's intended and supported behaviour. Other than those issues, it looks good to me. Rob Ok, I'm attaching another iteration. Incidentally, what's the official spelling of postinstall and preremove? Is it with a hyphen, with a space, or as one word? Uhm, dunno. one word sounds ok to me. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: Setup Query for Gary: FreeResource
On Sat, 2003-08-02 at 05:16, Max Bowsher wrote: According to the MS docs, FreeResource is an obsolete 16-bit compatibility function. Do we really want/need to use it? MS recommend using DeleteIcon etc rather than it for new code - and yes, its nice to free resources we've used :}. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Comments 2
approved.
ROb
On Sat, 2003-08-02 at 01:00, Max Bowsher wrote:
+2003-08-01 Gary R. Van Sickle [EMAIL PROTECTED]
+
+ * proppage.cc (PropertyPage::FirstDialogProcReflector): Modify comment.
Index: proppage.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/proppage.cc,v
retrieving revision 2.7
diff -u -p -r2.7 proppage.cc
--- proppage.cc 31 Jul 2003 12:21:21 - 2.7
+++ proppage.cc 1 Aug 2003 14:50:13 -
@@ -76,7 +76,7 @@ PropertyPage::FirstDialogProcReflector (
if (message != WM_INITDIALOG)
{
// Don't handle anything until we get a WM_INITDIALOG message, which
- // will have our this pointer with it.
+ // will have our 'this' pointer with it.
return FALSE;
}
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---
signature.asc
Description: This is a digitally signed message part
Re: [setup PATCH] Comments 1
Approved
Rob
On Sat, 2003-08-02 at 00:47, Max Bowsher wrote:
+2003-08-01 Gary R. Van Sickle [EMAIL PROTECTED]
+
+ * proppage.h (Copyright): Update copyright dates.
+ (PropertyPage): Document OnNext and OnBack.
Index: proppage.h
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/proppage.h,v
retrieving revision 2.6
diff -u -p -r2.6 proppage.h
--- proppage.h 29 Jul 2003 14:14:06 - 2.6
+++ proppage.h 1 Aug 2003 14:44:49 -
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, Gary R. Van Sickle.
+ * Copyright (c) 2001, 2002, 2003 Gary R. Van Sickle.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -99,6 +99,12 @@ public:
virtual void OnDeactivate ()
{
};
+
+ // Overload these to perform special processing when the user hits
+ // Next or Back. Return:
+ // 0 == Go to next/previous page in sequence.
+ // -1 == Prevent wizard from changing page.
+ // Resource ID == go to a specific page specified by the resource ID.
virtual long OnNext ()
{
return 0;
@@ -107,6 +113,7 @@ public:
{
return 0;
};
+
virtual bool OnFinish ()
{
return true;
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---
signature.asc
Description: This is a digitally signed message part
Re: [setup PATCH] SetDlgItemFont
On Thu, 2003-07-31 at 22:20, Max Bowsher wrote: ChangeLog says it all really - this is just an incremental tweak to make it easier to create a Finished page, and to have all our font stylings in one place. Note Gary had the SetDlgItemFont calls moved out in a seperate method. Given that they are almost the entire contents of the case WM_INITDIALOG, I don't think this is appropriate. Max. Well, factoring out code for clarity is a good thing - the separate function is appropriate. Can you resubmit with that.. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Add icon to title bar
So this puts a small icon in the top left - like most programs have?
Cool.
Approved,
Cheers,
Rob
On Sat, 2003-08-02 at 00:59, Max Bowsher wrote:
+2003-08-01 Gary R. Van Sickle [EMAIL PROTECTED]
+
+ * propsheet.cc: Include resource.h.
+ (PropSheet::Create): Add the Cygwin icon in the left of the title bar.
Index: propsheet.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/propsheet.cc,v
retrieving revision 2.4
diff -u -p -r2.4 propsheet.cc
--- propsheet.cc 1 May 2002 11:13:16 - 2.4
+++ propsheet.cc 1 Aug 2003 14:58:05 -
@@ -20,6 +20,7 @@
#include propsheet.h
#include proppage.h
+#include resource.h
//#include shlwapi.h
// ...but since there is no shlwapi.h in mingw yet:
@@ -172,8 +173,8 @@ PropSheet::Create (const Window * Parent
PageHandles = CreatePages ();
p.dwSize = GetPROPSHEETHEADERSize ();
- p.dwFlags =
-PSH_NOAPPLYNOW | PSH_WIZARD | PSH_USECALLBACK /*| PSH_MODELESS */ ;
+ p.dwFlags = PSH_NOAPPLYNOW | PSH_WIZARD | PSH_USECALLBACK
+/*| PSH_MODELESS */ | PSH_USEICONID;
if (Parent != NULL)
{
p.hwndParent = Parent-GetHWND ();
@@ -184,6 +185,7 @@ PropSheet::Create (const Window * Parent
}
p.hInstance = GetInstance ();
p.nPages = NumPropPages;
+ p.pszIcon = MAKEINTRESOURCE(IDI_CYGWIN);
p.nStartPage = 0;
p.phpage = PageHandles;
p.pfnCallback = PropSheetProc;
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---
signature.asc
Description: This is a digitally signed message part
Re: [setup PATCH] SetDlgItemFont
On Sat, 2003-08-02 at 09:12, Max Bowsher wrote: Now, I don't think moving 2 lines of code and 4 lines of comments into a seperate function makes this clearer - rather, it obfuscates what is happening here. In case you are not convinced, here is the alternate patch, to avoid another round-trip of emails: I'm not particularly fond of the name SetFontPolicy. Better names welcomed. call it void PropertyPage::setTitleFont(). And I'm not convinced - this is appropriate to be a separate function. Approved - as a separate function, called setTitleFont. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Rework do_ini [next_dialog removal (2a)]
On Tue, 2003-07-29 at 23:40, Max Bowsher wrote: Let's see if this approach is more satisfactory... We're getting close. However, you introduce a regression: currently alocal dir ini failure should just bounce em back to the previous screen IIRC, not exit. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Rework do_ini [next_dialog removal (2a)]
On Wed, 2003-07-30 at 18:34, Max Bowsher wrote: This is just as well, since currently if IDD_S_LOAD_INI does got posted back to threebar.cc, setup hangs on the progress page, since do_fromcwd does not do what the code in threebar.cc seems to believe it does. So, I'm adding an exit in a very narrow edge case (and the exit is implicitly a FIXME: Use an Exception). Ok, that makes sense. Please make a small note in the code - TODO, return to do_local_ini / the source selection screen, and also make it with //FIXME: throw an exception. Do those two things, and it's approved. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
new snapshot...
I've uploaded a new snapshot (-402) It's (obviously) got all the recent changes. It's -also- got persisted user settings for most of the dialogs. Take a look at SourceSettings.* or ConnectionSettings.* - they're /very/ simple. (They could be made simpler, but it just wasn't worth it there n then.) I'm considering moving that to release ASAP (because it fixes the /slow/ install time for new users), and then letting us spend some with the resizable dialog, working any kinks out. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Rework do_ini [next_dialog removal (2a)]
On Wed, 2003-07-30 at 20:08, Max Bowsher wrote: Actually, that TODO is trivial, so I've done it. Also found a bug in my previous patch (one SetActivePageByID (lParam) remained) - fixed. New patch (ini.cc changes are identical to previous patch): Ok, lets do it. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Setup.exe: Mouse wheel
On Sun, 2003-06-01 at 03:27, Benjamin Riefenstahl wrote: Finally it's not obviously the Right Thing to do. It seems to me we'd want to trap those events and translate them in the rest of the choose event loop, not as a special case. You mean in listview_proc()? I tried that, but the mouse wheel events didn't seem to get there at all. I've re-reviewed this, and it's definately the wrong place to do it. The events can get forwarded from the chooser's window procedure to the PickView for now IF they don't appear in PickView's window procedure - there's definately no need for a new static in chooser.cc. However, redrawing the chooser isn't the lightest task we do - we should consolidate the steps into one adjustment rather than looping. Finally, the PickView window procedure really should be receiving those events - but IIRC the containing control needs to forward them based on location. IIRC. The list view doesn't actually ever take the focus, at least the focus is never marked there and you can't click on the list view without changing some selection, except the scroll bars. So handling those messages at the dialog level actually seemed a good idea to me after some consideration. Yah, it's a bit blurry there what we should be doing. Long term though, I think we want to handle all navigation events within PickView, and only 'globals' like keep/curr/exp/prev within ChooserPage. What I didn't like in the code was that the interface of chooser-scroll() was not very abstract, using the event parameters of WM_[HV]SCROLL, that bit seems improvable. I wasn't prepared to introduce interface changes in that class, though. I'd rather introduce an appropriate interface change than a kludge. Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Pending setup patches (issue 15)
On Thu, 2003-07-31 at 07:54, Max Bowsher wrote: Or in to cvs right now, as is? This one Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] next_dialog micropatch (2)
On Tue, 2003-07-29 at 06:50, Max Bowsher wrote: You realise that *all* I am doing with this patch is to change how data is passed between a function and it's caller? Yes, and its that aspect I objected to. I don't understand what was so unclear. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: Er I mean... (was: RE: [PATCH] next_dialog micropatch (3)(was: RE: [setup PATCH] next_dialog micropatch (2)))
On Tue, 2003-07-29 at 13:47, Gary R. Van Sickle wrote:
...this straightforward patch:
2003-07-28 Gary R. Van Sickle [EMAIL PROTECTED]
* dialog.h (do_fromcwd): Change function declaration.
* fromcwd.cc (do_fromcwd): Change return type to bool. Eliminate
use of next_dialog, return true or false instead.
* localdir.cc (LocalDirPage::OnNext): Use do_fromcwd()'s return
value instead of next_dialog.
Approved, subject to one caveat:
instead of
bool found_ini;
found_ini = do_fromcwd ()..
if (found_ini)
please use
if (do_fromcwd(...)) {
unneeded temporary variables are annoying.
Cheers,
Rob
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---
signature.asc
Description: This is a digitally signed message part
