From: Scott 'm. M. <me...@fa...> - 2002-03-29 00:15:38
|
If you DL the non-binary version it includes a bunch of useful sample scripts to demonstrate the controls, as well as some tutorials, among other useful bits. - me22 > Date: Wed, 27 Mar 2002 20:07:27 -0800 (PST) > From: emir cruz <mi...@ya...> > To: per...@li... > Subject: [perl-win32-gui-users] on list views > > hi! I am a newbie in perl and the win32 module... > > could u guys tell me how do i delete an item in > a list view and refresh the list view? > > and also.. is there a more comprehensive documentation > on the module? i find the one bundled with release > somewhat incomplete. > > thx. _________________________________________________________________ http://fastmail.ca/ - Fast Secure Web Email for Canadians |
From: Reini U. <ru...@x-...> - 2009-07-12 18:23:21
|
Kevin Marshall schrieb: > Reini, > > Here is my updated version of the Win32::GUI Documentation. If you have > any questions or comments, please post them on the mailing list. That's the problem and that's what I've thought. You were fixing the *generated* pod files, but not the source of the documentation. The source for those pods are the comments in the modules. On the next *make poddocs* your tree is overwritten. A diff will be preferred then, to merge it into the sources. I'll see what I can do. > Attachment: > Name: Win32-GUI-Docs-1.01.tar.gz > Size: 148643 B > MD5: 3095e99e8ae34c97fb1187ff432064bd > > The docs are in POD format. If you want them in HTML, use pod2html. > Hope these are useful. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Kevin M. <kej...@ho...> - 2009-07-13 00:41:36
|
Reini, I understand where you are coming from, a diff would make replacement of the original files easier. I was, however, considering a complete rewrite of the documentation, including the structure, which would make patching the existing files interesting. An alternative would be to copy my docs over the docs generated in the build process, before doing "make install". Another way would be to edit the makefile to prevent the docs being generated, then move my docs into their place, then do "make install". For those people who use the PPMs they have less options. The best they can do is copy my docs over the originals after installing the PPM. It was suggested I set up a dedicated website for the documentation. This would certainly overcome any of these problems. Kevin. > Date: Sun, 12 Jul 2009 20:25:06 +0200 > From: ru...@x-... > To: kej...@ho...; per...@li... > Subject: Re: Win32::GUI Documentation > > Kevin Marshall schrieb: > > Reini, > > > > Here is my updated version of the Win32::GUI Documentation. If you have > > any questions or comments, please post them on the mailing list. > > That's the problem and that's what I've thought. > You were fixing the *generated* pod files, but not the source of the > documentation. The source for those pods are the comments in the > modules. On the next *make poddocs* your tree is overwritten. > > A diff will be preferred then, to merge it into the sources. I'll see > what I can do. > > > Attachment: > > Name: Win32-GUI-Docs-1.01.tar.gz > > Size: 148643 B > > MD5: 3095e99e8ae34c97fb1187ff432064bd > > > > The docs are in POD format. If you want them in HTML, use pod2html. > > Hope these are useful. > > -- > Reini Urban > http://phpwiki.org/ http://murbreak.at/ _________________________________________________________________ Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn property http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT |
From: Kevin M. <kej...@ho...> - 2009-07-13 02:49:14
|
Glenn, Yes, you're right, the documentation for the module is contained within the source code and is extracted during the build process. For a module this large, it probably made sense in the beginning to use this method to create the docs, but as the module has grown, I imagine it has become more difficult to manage. Perhaps moving the documentation into their own files is something for the developers to look at for the next release. Most of the changes I made to the docs involved replacing the TBD sections with the required information, as well as supplying more information about input parameters and return values for most of the functions. Kevin. > Date: Sun, 12 Jul 2009 18:23:30 -0700 > From: pe...@ne... > To: kej...@ho... > CC: ru...@x-...; per...@li... > Subject: Re: [perl-win32-gui-users] Win32::GUI Documentation > > On approximately 7/12/2009 5:41 PM, came the following characters from > the keyboard of Kevin Marshall: > > Reini, > > > > I understand where you are coming from, a diff would make replacement > > of the original files easier. I was, however, considering a complete > > rewrite of the documentation, including the structure, which would > > make patching the existing files interesting. An alternative would be > > to copy my docs over the docs generated in the build process, before > > doing "make install". Another way would be to edit the makefile to > > prevent the docs being generated, then move my docs into their place, > > then do "make install". For those people who use the PPMs they > > have less options. The best they can do is copy my docs over the > > originals after installing the PPM. It was suggested I set up a > > dedicated website for the documentation. This would certainly overcome > > any of these problems. > > Well, a dedicated website for the documentation only works-around these > problems. I think presently the source for the documentation is in the > source code files for the modules. If that is preserved, it is more > likely that the documentation will get updated when the code gets updated. > > Even if you do a complete rewrite of the documentation, if it is not > integrated with the module source in some way, it will likely not get > maintained over time. > > That said, I agree that the documentation could use some help; last I > looked at it, there were lots of TBD areas. > > _________________________________________________________________ View photos of singles in your area Click Here http://dating.ninemsn.com.au/search/search.aspx?exec=go&tp=q&gc=2&tr=1&lage=18&uage=55&cl=14&sl=0&dist=50&po=1&do=2&trackingid=1046138&r2s=1&_t=773166090&_r=WLM_EndText |
From: Glenn L. <pe...@ne...> - 2009-07-13 01:50:20
|
On approximately 7/12/2009 5:41 PM, came the following characters from the keyboard of Kevin Marshall: > Reini, > > I understand where you are coming from, a diff would make replacement > of the original files easier. I was, however, considering a complete > rewrite of the documentation, including the structure, which would > make patching the existing files interesting. An alternative would be > to copy my docs over the docs generated in the build process, before > doing "make install". Another way would be to edit the makefile to > prevent the docs being generated, then move my docs into their place, > then do "make install". For those people who use the PPMs they > have less options. The best they can do is copy my docs over the > originals after installing the PPM. It was suggested I set up a > dedicated website for the documentation. This would certainly overcome > any of these problems. Well, a dedicated website for the documentation only works-around these problems. I think presently the source for the documentation is in the source code files for the modules. If that is preserved, it is more likely that the documentation will get updated when the code gets updated. Even if you do a complete rewrite of the documentation, if it is not integrated with the module source in some way, it will likely not get maintained over time. That said, I agree that the documentation could use some help; last I looked at it, there were lots of TBD areas. |
From: Glenn L. <pe...@ne...> - 2009-07-13 03:33:24
|
On approximately 7/12/2009 7:49 PM, came the following characters from the keyboard of Kevin Marshall: > Glenn, > > Yes, you're right, the documentation for the module is contained > within the source code and is extracted during the build process. For > a module this large, it probably made sense in the beginning to use > this method to create the docs, but as the module has grown, I imagine > it has become more difficult to manage. Perhaps moving the > documentation into their own files is something for the developers to > look at for the next release. Most of the changes I made to the docs > involved replacing the TBD sections with the required information, as > well as supplying more information about input parameters and return > values for most of the functions. Seems to me that the larger a project gets, the better it is for the documents to be in the source... because if something is changing in the code, the change to the documentation is right there too. However, you seem to hold the opinion that having separate documentation files would be better in some unstated way? I haven't had a chance to read your updated docs, but the kinds of changes you describe sound extremely helpful. While I hold a commit bit to the repository, and have made some minor bug fixes in the past, the primary developer in recent years has been Rob May... but I think he got busy with other things, and hasn't been very active here lately, which is sad for this module, as he was doing some excellent things to it. So at the present time, I'm not sure 1) if there are any active developers 2) if there are any that would agree that moving the documentation to separate files would be a good thing 3) who would apply your documentation patches to the repository, even if you submitted them that way, rather than creating your own web site I don't remember if Reini has a commit bit or not, but I don't think he's ever built a release. There have been significant changes to sourceforge in the intervening period, as well, so it would take some learning curve for me (and probably for Reini, although maybe he's up on the sourceforge changes from other projects) to attempt to build a release, methinks. Or maybe Rob will poke his head in here, and say that he could find some time to commit some doc changes and build a new release... |
From: Jack C. <ja...@mo...> - 2009-07-13 04:20:06
|
I haven't read the new docs either, and can only speak as a user of Win32::GUI, but I do use it a lot, and find the current doc situation challenging. The Right Thing To Do is probably fixing the POD, but right often gets in the way of done. If correct docs can be posted somewhere, that's better than nothing. I'm willing to help out insofar as I can. Jack On 7/12/09, Glenn Linderman <pe...@ne...> wrote: > On approximately 7/12/2009 7:49 PM, came the following characters from > the keyboard of Kevin Marshall: >> Glenn, >> >> Yes, you're right, the documentation for the module is contained >> within the source code and is extracted during the build process. For >> a module this large, it probably made sense in the beginning to use >> this method to create the docs, but as the module has grown, I imagine >> it has become more difficult to manage. Perhaps moving the >> documentation into their own files is something for the developers to >> look at for the next release. Most of the changes I made to the docs >> involved replacing the TBD sections with the required information, as >> well as supplying more information about input parameters and return >> values for most of the functions. > > Seems to me that the larger a project gets, the better it is for the > documents to be in the source... because if something is changing in the > code, the change to the documentation is right there too. > > However, you seem to hold the opinion that having separate documentation > files would be better in some unstated way? > > I haven't had a chance to read your updated docs, but the kinds of > changes you describe sound extremely helpful. > > While I hold a commit bit to the repository, and have made some minor > bug fixes in the past, the primary developer in recent years has been > Rob May... but I think he got busy with other things, and hasn't been > very active here lately, which is sad for this module, as he was doing > some excellent things to it. > > So at the present time, I'm not sure > 1) if there are any active developers > 2) if there are any that would agree that moving the documentation to > separate files would be a good thing > 3) who would apply your documentation patches to the repository, even if > you submitted them that way, rather than creating your own web site > > I don't remember if Reini has a commit bit or not, but I don't think > he's ever built a release. There have been significant changes to > sourceforge in the intervening period, as well, so it would take some > learning curve for me (and probably for Reini, although maybe he's up on > the sourceforge changes from other projects) to attempt to build a > release, methinks. Or maybe Rob will poke his head in here, and say > that he could find some time to commit some doc changes and build a new > release... > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Perl-Win32-GUI-Users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > http://perl-win32-gui.sourceforge.net/ > > -- Sent from my mobile device "I spent all me tin with the ladies drinking gin, So across the Western ocean I must wander" -- traditional |
From: Reini U. <ru...@x-...> - 2009-07-13 07:51:52
|
2009/7/13 Glenn Linderman <pe...@ne...>: > So at the present time, I'm not sure > 1) if there are any active developers > 2) if there are any that would agree that moving the documentation to > separate files would be a good thing > 3) who would apply your documentation patches to the repository, even if > you submitted them that way, rather than creating your own web site > > I don't remember if Reini has a commit bit or not, No, I don't think I have a commit bit. > but I don't think he's ever built a release. No, I'm doing all the cygwin releases since years. > There have been significant changes to > sourceforge in the intervening period, as well, so it would take some > learning curve for me (and probably for Reini, although maybe he's up on > the sourceforge changes from other projects) to attempt to build a > release, methinks. Or maybe Rob will poke his head in here, and say > that he could find some time to commit some doc changes and build a new > release... I maintain phpwiki on sf.net and it gets worse and worse. But posting releases is still simple. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Glenn L. <pe...@ne...> - 2009-07-14 06:16:43
|
On approximately 7/13/2009 12:51 AM, came the following characters from the keyboard of Reini Urban: > 2009/7/13 Glenn Linderman <pe...@ne...>: > >> So at the present time, I'm not sure >> 1) if there are any active developers >> 2) if there are any that would agree that moving the documentation to >> separate files would be a good thing >> 3) who would apply your documentation patches to the repository, even if >> you submitted them that way, rather than creating your own web site >> >> I don't remember if Reini has a commit bit or not, >> > > No, I don't think I have a commit bit. > > >> but I don't think he's ever built a release. >> > > No, I'm doing all the cygwin releases since years. > That's right! I knew you were involved somehow, but couldn't remember how. Of course building the cygwin package, is taking a release, and building and packaging it. Really, building a release is likely simple, although likely changed since I last did it, in the sense of the file manipulations required, but the hard part comes in doing sufficient testing to be convinced that it is a good release. And there are more parts now than last I did it. I worked only on very focused bug fixes, even then. >> There have been significant changes to >> sourceforge in the intervening period, as well, so it would take some >> learning curve for me (and probably for Reini, although maybe he's up on >> the sourceforge changes from other projects) to attempt to build a >> release, methinks. Or maybe Rob will poke his head in here, and say >> that he could find some time to commit some doc changes and build a new >> release... >> > > I maintain phpwiki on sf.net and it gets worse and worse. > Could you elaborate? I'm not sure what this is. > But posting releases is still simple. > That sounds good. |
From: Rob M. <ro...@th...> - 2009-07-14 17:26:26
|
Kevin et al., Many thanks for taking a look at this, it is certainly true that the documentation is lacking in many areas. I haven't been able to look at the work you've done, as none of the mail I have seen have any attachments (it's possible that the SourceForge mail ing list strip zip files?) Whilst I am not going to try to stop any activity in this area, I have some observations that you may choose to guide your activities: (1) My supply of tuits is very small, so I doubt that I will contribute much. (2) I am happy to give a commit bit to anyone who wants to commit changes to the core source code. (3) For the core documentation (i.e. functional documentation of the classes/methods within the Win32::GUI distribution) I'd like to see the docs reside within the source repository and be distributed with Win32::GUI. Fundamentally this means writing POD (which gets converted to HTML during the build process) or embedded docs as we currently have, with a suitable toolset for pulling the embedded docs into pod during the build[1]. An investigation into what other larger projects do might be worthwhile. (4) For other documentation (Tutorials etc) I am less concerned that they are kept in the core source, but would propose that they be hosted somewhere related to the project - as a first suggestion I'd be happy to give someone enough permissions to have a play with the hosted apps that SourceForge now offer (which weren't available last time I looked). There's certainly wiki and other documentation tools available there. Of course, it may be that none of the offered solutions suit us. (5) For experience, if we don't find a way to merge your changes in to the core documentation, or host them somewhere where someone else can take over maintenance, then they will drop into disuse over time. It is my experience that the closer you can put the documentation to the code it is documenting, the more likely that it will be kept up to date. Finally, I am also seeking someone who would be happy to take over the maintenance of the Win32::GUI website - it could do with a re-vamp and some TLC. Any takers? This work might tie in nicely with moving us over to a new Wiki (or similar). Thanks for all the interest. Rob. [1] It would actually be better to have the embedded docs pulled into POD before the build, so that source distributions to CPAN get their POD displayed properly. 2009/7/14 Glenn Linderman <pe...@ne...>: > On approximately 7/13/2009 12:51 AM, came the following characters from > the keyboard of Reini Urban: >> 2009/7/13 Glenn Linderman <pe...@ne...>: >> >>> So at the present time, I'm not sure >>> 1) if there are any active developers >>> 2) if there are any that would agree that moving the documentation to >>> separate files would be a good thing >>> 3) who would apply your documentation patches to the repository, even if >>> you submitted them that way, rather than creating your own web site >>> >>> I don't remember if Reini has a commit bit or not, >>> >> >> No, I don't think I have a commit bit. >> >> >>> but I don't think he's ever built a release. >>> >> >> No, I'm doing all the cygwin releases since years. >> > > That's right! I knew you were involved somehow, but couldn't remember > how. Of course building the cygwin package, is taking a release, and > building and packaging it. Really, building a release is likely simple, > although likely changed since I last did it, in the sense of the file > manipulations required, but the hard part comes in doing sufficient > testing to be convinced that it is a good release. And there are more > parts now than last I did it. I worked only on very focused bug fixes, > even then. > >>> There have been significant changes to >>> sourceforge in the intervening period, as well, so it would take some >>> learning curve for me (and probably for Reini, although maybe he's up on >>> the sourceforge changes from other projects) to attempt to build a >>> release, methinks. Or maybe Rob will poke his head in here, and say >>> that he could find some time to commit some doc changes and build a new >>> release... >>> >> >> I maintain phpwiki on sf.net and it gets worse and worse. >> > > Could you elaborate? I'm not sure what this is. > >> But posting releases is still simple. >> > > That sounds good. > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Perl-Win32-GUI-Users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > http://perl-win32-gui.sourceforge.net/ > |
From: Reini U. <ru...@x-...> - 2009-07-14 21:48:46
|
2009/7/14 Glenn Linderman <pe...@ne...>: >> I maintain phpwiki on sf.net and it gets worse and worse. > > Could you elaborate? I'm not sure what this is. For years we could host phpwiki on the sf.net webservers but then they removed the cronjobs, then the shared NFS disc, then the shell, then persistent mysql was broken, then their webserver proxy could not deal anymore with our app leading to cpu-eating cycles in various subrequest scenarios, and now the layout change. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |