Re: [pgadmin-hackers] RFC: Update wizard
Miha Radej wrote: hi! Andreas Pflug wrote: Annoying, if you don't want to update. Maybe non-flashing. Or toolbar button, which changes appearance if download is available. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. could you also consider checking for a newer binary snapshot (for windows in my case)? so i wouldn't have to go look every now and then :) i know, i'm being lazy :) The update information checked by pgadmin will be created manually, i.e. it's a kind of release information. We're probably too lazy to update it for every snapshot ;-) Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 12:18 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard Dave Page wrote: Not directly. The binaries would be corrupted. In the rare case of typo fixes without count change the count could be increased manually. It's a kind of version number anyway. We could use the date too. Why would binaries be corrupted? CVS would change the file to insert the version, which would probably corrupt the binary structure. No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. In that case then, why distribute the languages seperately? I don't understand the question. We *do* distribute the languages packaged, no? I think I was asking why we shouldn't include the languages in the update zip file, but it was a few days ago now :-) Forget about it! As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. Disabling autocheck and not updating immediately are different things. The option controls the background checking for updates. If you then double click the alert icon, a dialogue is presented allowing you to select a mirror and download. Speaking of which, we will need to have a list of mirrors on the main webserver that can be downloaded... That is not a problem though. Every 60 days (e.g.) updates are checked, and a feedback is given to the user. After that, the user might decide to upgrade immediately, or do it later. Statusbar icon seems the best solution (but it will need some effort; tooltip and doubleclick on that icon must be supported) Yeah. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? I think I was asking why we shouldn't include the languages in the update zip file, but it was a few days ago now :-) Forget about it! ?!? You can consider zip as another compression/packaging format, similar to chm. I'm not sure whether wxLocale can handle this too. As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. Disabling autocheck and not updating immediately are different things. The option controls the background checking for updates. If you then double click the alert icon, a dialogue is presented allowing you to select a mirror and download. Its not as easy as that... for pgadmin base package, I'd only inform about new packages. I wonder if we can do this even system specific, i.e. inform about deb packages on debian, ... For languages, a more complex selection for updating existing and adding new ones is necessary. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:19 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? CVS doesn't have to mark the file internally. Consider what happens if you try to check out a specific revision of a file - we can do that via the web, eg: http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin 3.po?rev=1.20 Gets us rev 1.20. In a similar was it shouldn't be difficult to query cvs for the latest version number of a given file. Its not as easy as that... for pgadmin base package, I'd only inform about new packages. I wonder if we can do this even system specific, i.e. inform about deb packages on debian, ... Even if it just opened a browser at the selected mirror it would be helpful. Other than that, how do we determine the exact OS (ie. the difference between redahat9 and suse8 for example)? For languages, a more complex selection for updating existing and adding new ones is necessary. Yeah, though that shouldn't be a major problem as they're platform independent. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:19 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? CVS doesn't have to mark the file internally. Consider what happens if you try to check out a specific revision of a file - we can do that via the web, eg: http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin 3.po?rev=1.20 Gets us rev 1.20. In a similar was it shouldn't be difficult to query cvs for the latest version number of a given file. First, do we really want to hammer CVS for each update check? I'd think having this in an available versions file is sufficient. Second, the issue is not to retrieve a version, but to identify the version of the language file currently in use. We need an identifyable string inside the file for that. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: More preciesly, the issue is to detect whether a file has been updated. I suggested CVS as it should be simple to initial look for a file newer than the releases CVS tag, and following that, newer than the one previously downloaded. But we don't want to create a kind-of cvs client in pgadmin, no? How to identify the currently installed versions, if not with a version string compiled in? Mind you, maybe I'm underestimating the number of users we may get. Perhaps this should work from the ftp mirror network? I've been asking about this a while ago. We don't know until we try, I'm afraid... Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 14:46 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard Dave Page wrote: More preciesly, the issue is to detect whether a file has been updated. I suggested CVS as it should be simple to initial look for a file newer than the releases CVS tag, and following that, newer than the one previously downloaded. But we don't want to create a kind-of cvs client in pgadmin, no? How to identify the currently installed versions, if not with a version string compiled in? For a new install, get the file if it is newer than the build date. Once a file is downloaded, it's modification date is logged in the registry and used for future checks. I wasn't proposing a CVS client in pgAdmin BTW - viewcvs with appropriate templates should be easily parse-able, and it can certainly serve files of any version, from any branch. Mind you, maybe I'm underestimating the number of users we may get. Perhaps this should work from the ftp mirror network? I've been asking about this a while ago. We don't know until we try, I'm afraid... No, but it might be better to assume the worst... Doing it this way, it shouldn't be too difficult to automate an extraction from CVS onto the master server, and generate an index file of what's there. The more I think about it, the more that seems the best option... Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 16:08 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard I was afraid you mentioned __TDATE__. This is evaluated at compile time, i.e. precautions must be taken that the file must be compiled even if unchanged. I do a 'make clean;make all' or 'Rebuild All' as a matter of course anyway - I would hope the other packagers do as well. Second, the date is formatted, i.e. we must unformat it locale/lib/compiler/??? dependent before examining. Hmm, shouldn't be - __DATE__ is supposed to always be Mmm dd iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if the Mmm ever appears in different languages though. /D ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: Second, the date is formatted, i.e. we must unformat it locale/lib/compiler/??? dependent before examining. Hmm, shouldn't be - __DATE__ is supposed to always be Mmm dd iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if the Mmm ever appears in different languages though. That's the part I'm afraid about. Win32 doc says only using asctime() format. asctime doc doesn't say anything about language dependency. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 22 November 2004 17:26 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard That won't necessarily pick up typos of course. Can we utilise CVS for this somehow, and use it's built in version numbering? Not directly. The binaries would be corrupted. In the rare case of typo fixes without count change the count could be increased manually. It's a kind of version number anyway. We could use the date too. Why would binaries be corrupted? That'll even allow segregation of major version updates using branch version numbers. We don't need that. A newer language file also covers previous versions. Does it? You mean, if we remove strings from the source, they remain in the po files after a merge? Seems kinda inefficient... Have you thought about documentation updates? Um, no. No problem really, because we already can load the doc from a zip. Consequently, we should stop distributing single files, and distribute the zip only. In that case then, why distribute the languages seperately? Questions: - How to inform the user about possible updates? MsgBox? Toolbar button showing enabled? Update check will be performed asynchronously, so it might pop up in the middle of something. Status bar message with flashing icon? Annoying, if you don't want to update. Maybe non-flashing. As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. Or toolbar button, which changes appearance if download is available. No, I don't think we should use the tool bar. It's there to allow the user to control the application, not to provide feedback. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. Yes, agreed. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: We have three areas to update: - The program itself. We will just notify the user that there's something new he might be interested in (depending on beta/release). An option to download/install would be nice. That would require a separate program on Windows of course to update the main executable. Apart from packaging conflicts, IMHO it's not worth it. Pointing to the website should be sufficient. - the current language. A word count can be used as version. Automatic download/installation possible. That won't necessarily pick up typos of course. Can we utilise CVS for this somehow, and use it's built in version numbering? Not directly. The binaries would be corrupted. In the rare case of typo fixes without count change the count could be increased manually. It's a kind of version number anyway. We could use the date too. That'll even allow segregation of major version updates using branch version numbers. We don't need that. A newer language file also covers previous versions. Have you thought about documentation updates? Um, no. No problem really, because we already can load the doc from a zip. Consequently, we should stop distributing single files, and distribute the zip only. Questions: - How to inform the user about possible updates? MsgBox? Toolbar button showing enabled? Update check will be performed asynchronously, so it might pop up in the middle of something. Status bar message with flashing icon? Annoying, if you don't want to update. Maybe non-flashing. Or toolbar button, which changes appearance if download is available. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. - We could post some statistical data about the pga installation (OS/version/backend versions/server count/???) to get a little feedback; how to collect these? I'd love to see this sort of info, *however*, I have little doubt the privacy advocates would have something to say about it. I would be *very* wary of adding such a feature. lets discuss this separately. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
hi! Andreas Pflug wrote: Annoying, if you don't want to update. Maybe non-flashing. Or toolbar button, which changes appearance if download is available. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. could you also consider checking for a newer binary snapshot (for windows in my case)? so i wouldn't have to go look every now and then :) i know, i'm being lazy :) regards, Miha ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[pgadmin-hackers] RFC: Update wizard
Hi friends, preparing for the forthcoming 1.3/1.4 version, I'm already prototyping a little on automatic updates, and there are a lot of decisions to take. We have three areas to update: - The program itself. We will just notify the user that there's something new he might be interested in (depending on beta/release). - the current language. A word count can be used as version. Automatic download/installation possible. - a different language, which might require an update pgadmin3.lng too. Since the language isn't necessarily loaded, no version check can be performed. Questions: - How to inform the user about possible updates? MsgBox? Toolbar button showing enabled? Update check will be performed asynchronously, so it might pop up in the middle of something. - Dedicated update dialog or an options tab? - We could post some statistical data about the pga installation (OS/version/backend versions/server count/???) to get a little feedback; how to collect these? Multiple opinions welcome. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug Sent: 21 November 2004 18:05 To: pgadmin-hackers Subject: [pgadmin-hackers] RFC: Update wizard Hi friends, preparing for the forthcoming 1.3/1.4 version, I'm already prototyping a little on automatic updates, and there are a lot of decisions to take. We have three areas to update: - The program itself. We will just notify the user that there's something new he might be interested in (depending on beta/release). An option to download/install would be nice. That would require a separate program on Windows of course to update the main executable. - the current language. A word count can be used as version. Automatic download/installation possible. That won't necessarily pick up typos of course. Can we utilise CVS for this somehow, and use it's built in version numbering? That'll even allow segregation of major version updates using branch version numbers. - a different language, which might require an update pgadmin3.lng too. Yup. Since the language isn't necessarily loaded, no version check can be performed. No. Have you thought about documentation updates? Questions: - How to inform the user about possible updates? MsgBox? Toolbar button showing enabled? Update check will be performed asynchronously, so it might pop up in the middle of something. Status bar message with flashing icon? - Dedicated update dialog or an options tab? I would say both. A dialogue to handle the actual updating, and maybe one or two options to allow changes to the download location, enable/disable checking options etc. - We could post some statistical data about the pga installation (OS/version/backend versions/server count/???) to get a little feedback; how to collect these? I'd love to see this sort of info, *however*, I have little doubt the privacy advocates would have something to say about it. I would be *very* wary of adding such a feature. Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug Sent: 21 November 2004 18:05 To: pgadmin-hackers Subject: [pgadmin-hackers] RFC: Update wizard Hi friends, preparing for the forthcoming 1.3/1.4 version, I'm already prototyping a little on automatic updates, and there are a lot of decisions to take. We have three areas to update: - The program itself. We will just notify the user that there's something new he might be interested in (depending on beta/release). An option to download/install would be nice. That would require a separate program on Windows of course to update the main executable. What are you thinking about exactly ? A way to specify an external script/command to launch or something ? Under Linux and maybe others, I think that updaters generally do exactly the same thing, but generally less efficiently, as the native packaging systems. Example: I love the pear system for php but I consider that it clashes with the native packaging tools under Debian... By using pear system you get unpackaged files installed on your system. And what about things partly installed (example data files not up to date with binaries) which may break the app... I'd be for something advertising a new version but not more. Unless we have something really open and customisable to suits the needs of all OSes packagers. Regards, Raphaël ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Raphaël Enrici [mailto:[EMAIL PROTECTED] Sent: 21 November 2004 21:39 To: Dave Page; Andreas Pflug Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard What are you thinking about exactly ? A way to specify an external script/command to launch or something ? Under Linux and maybe others, I think that updaters generally do exactly the same thing, but generally less efficiently, as the native packaging systems. Example: I love the pear system for php but I consider that it clashes with the native packaging tools under Debian... By using pear system you get unpackaged files installed on your system. And what about things partly installed (example data files not up to date with binaries) which may break the app... I'd be for something advertising a new version but not more. Unless we have something really open and customisable to suits the needs of all OSes packagers. Yeah, that's the downside. On some apps I've used on Windows, it's nice get have the app download a new version of itself, and spawn a new process to move the new version into place and run it. Makes it all seamless and very slick. Doesn't fit in well with Linux packaging schemes though does it :-( Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
