IgorExchange.com Wish List (locked)
aclight
While we've done our best to add as many features to IgorExchange as we can, we're sure to have left some out. That's why we want your help. Please tell us what features you would like to see implemented here by replying to this post. We will keep these ideas in mind as we continue to improve the site.
Note: This discussion is for IgorExchange.com suggestions only. To make suggestions for Igor Pro, please see the Igor Pro Wish List discussion.
Just so you know, here are some features we are planning to add but haven't gotten to yet (in no particular order):
- Ability to sign up to be notified of new forum posts and replies
- Ability to sign up to be notified of new releases of projects
WaveMetrics, Inc.
support@wavemetrics.com
Adam: Is there a place to report problems? On the projects page, the link for Graphing shows 1 project, but clicking the link just re-displays the projects page.
Oh- probably through the Contact tab, eh?
August 15, 2007 at 09:26 am - Permalink
Hi John
This is a bug that I know about and am working on fixing. This happens because only projects that have releases are listed, however all projects are counted. Thus there is a discrepancy for projects with no releases.
As for reporting problems, the Contact tab is the best place to do this, since I'm sure to get the message.
Thanks
Adam
August 15, 2007 at 03:02 pm - Permalink
August 23, 2007 at 04:19 pm - Permalink
looks good so far. My work asks that I keep track of the code downloads that I produce. Is it possible, if I create a project, for the download statistics to be kept?
cheers,
Andy Nelson
September 11, 2007 at 11:53 pm - Permalink
Having a project submission feature is quite handy.
Here are some other suggestions:
1) Having a documentation section. e.g. People can write documention code for their project, or documentation for doing things in IGOR.
2) Having a useful code snippets section. I often find these out from the mailing list, but it's less persistent than having it written down.
cheers,
Andy
September 12, 2007 at 12:03 am - Permalink
Are you asking if it's possible to track the number of times that a given file is downloaded? If so, we do track that via Google Analytics but there isn't a way for anyone to see those results unless they have access to our Google Analytics account.
IMHO, it would be really cool if Igor Pro itself had knowledge of IgorExchange projects being used on an individual's computer and could query the server to see if an updated version was available. The server has the capability to do this and to keep track of the # of users checking for updates, but I would guess that this could be complicated to do from the Igor Pro side of things.
September 12, 2007 at 06:17 am - Permalink
Thanks for the suggestions. These are both good ideas, and I've added them to the wish list.
Thanks,
Adam
September 12, 2007 at 06:22 am - Permalink
September 12, 2007 at 06:46 am - Permalink
I will look into whether it is possible to get Google Analytics information in a parseable form and relay that information to project developers.
Adam
September 12, 2007 at 04:38 pm - Permalink
At Andy's request, I have created a code snippets section at http://www.igorexchange.com/code-snippets
All users who have logged in may create code snippets, and in addition any user may edit any other user's code snippet (this should help keep them from getting out of date). I'm not sure if I will keep it so that any user can edit any snippet (spam may be a problem) but we'll see how it goes for now.
Take a look and see what you think.
Adam
September 14, 2007 at 01:21 pm - Permalink
Sounds like a good idea.
September 17, 2007 at 12:52 pm - Permalink
I just posted a reply on the Igor Wish List thread:
http://www.igorexchange.com/node/134
1) When you click the Quote button (or even the Reply button) the Comment box is pre-loaded with signature text. But the signature is automatically added anyway, so my signature appeared twice.
2) Is it possible to edit a posting? Some forums allow you to edit a posting if you do it within a certain amount of time.
3) I can't find an obvious way to cancel a posting that you have started to prepare.
Thanks, Adam!
September 28, 2007 at 10:14 am - Permalink
I've made a note to fix this. The down side is that the original forum post can never have signatures in it. But I think that's preferable to having the potential for double signatures.
Drupal allows editing, but the problem is that we use flat (instead of threaded) forums, and comments are sorted and displayed based on the timestamp of their creation or last edit, whichever is later. So if a comment is edited its position in the list of comments would change, and that would be confusing.
It should be possible for users to edit their own forum topics (the original post, that is) but only administrative users can edit comments. I'll look into modifying the comments module to not change the timestamp upon editing, and if I can do that I think it would be OK to allow users to edit their comments.
Just like with all types of content, Drupal doesn't provide any cancel button. All you have to do to "cancel" is just not Submit the comment/post/etc. You can click the back button on your browser or just go to another page. Nothing is saved in the database until the "Submit" or "Save" or "Post" button is clicked.
September 29, 2007 at 01:52 pm - Permalink
FYI, I've now fixed this. But there's a catch. In that past, the double display of signatures was due to 1) The signature stored in the text of the comment itself, assuming you forgot to delete it, and 2) Display of each user's signature at the bottom of their post/comment. I've disabled display of #2, but the catch is that since in #1 the signatures are stored with the comment text, they are static. So if you change your signature, it will change in any new comments/replies you make, but not in any previous ones. It's not possible to disable #1 from happening. If you don't plan on changing your signature any time soon, then you don't have anything to worry about. However, if you do, I'd just recommend not using a signature. The next version of Drupal will have much better handling of signatures, but that's still a few months off.
October 10, 2007 at 04:23 pm - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
October 11, 2007 at 09:50 am - Permalink
[/quote]
I have re-enabled editing of comments by users. All users who have signed in should be able to edit forum posts by clicking the edit button under each comment. Comments on some other content types (such as code snippets) are not editable if they have been replied to directly. See instructions at Commenting on a post for details.
October 17, 2007 at 11:56 am - Permalink
John
I agree that the "new" indications are a bit inconsistent. The reason is that most content types (eg. projects, code snippets, forum posts) are what Drupal calls a "node". Nodes get the pink "new" text next to them when they are updated. When a new comment is added to a node (eg. a reply to a forum posting), the "node" itself is not new, so it doesn't get the "new" indicator. However, there are new comments and thus the new comments are linked to in the replies column.
Now, if someone starts a new topic in a forum (instead of posting a reply/comment to an existing topic), the "new" indicator will be present. But getting the topic title to be marked as new when there were new comments/replies to that topic would be quite difficult.
Adam
October 19, 2007 at 02:15 pm - Permalink
I've started tracking downloads and the counts for each project as well as each release are displayed on the respective pages. One caveat with this though--previously file download URLs looked like:
http://www.igorexchange.com/files/MyIgorPackage.zip
These style URLs will still work, however any downloads made using such URLs won't be counted (since that path is a real path instead of a virtual path and is handled directly by the web server). Instead, if you want the download to be counted, you should direct users to download from URLs like this:
http://www.igorexchange.com/project_download/files/MyIgorPackage.zip
All download links on the site should use these new style URLs, so you don't have to figure out the URL yourself.
Note: URLs for file attachments other than project releases (such as attachments, etc.) still use the old URL format and downloads for these files are not counted.
BTW, download counts start now. So all releases/projects will have 0 downloads as of the time of this posting. Even though many of them have been downloaded by users in the past, those downloads were not counted at the time.
October 21, 2007 at 04:43 pm - Permalink
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
November 1, 2007 at 05:57 am - Permalink
That would probably be pretty tricky, but I'll look into it.
For now, I'd recommend the download statistics page. This will only show you downloads by project, and not release, but that should be a good start.
November 1, 2007 at 07:21 am - Permalink
How do we add the flashy red "NEW" tag after the name of a project or code snippet?
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 8, 2008 at 03:40 pm - Permalink
You don't. The "New" tag is visible to users who have logged in but have not yet viewed that particular project, forum posting, etc. An "Updated" tag is also present for projects and project issues that have been modified since the user last viewed them.
"New" tags are only present on nodes (projects, forum postings, etc.) which are <30 days old. After 30 days, even if you have not yet viewed a node, it will not be marked as new.
Since the pages that each user has viewed are tracked, you obviously won't see these tags if you have not logged into the site.
Adam
January 9, 2008 at 01:25 pm - Permalink
I was interested to see that even after I posted the B02 revision, people continued to download B01. I presume that's because it's listed at the top of the column. This brings up a couple of questions:
1) Am I misunderstanding how I should be going about the releases? I want my package to continue to be version 2.00, because that's what I want it to be when released as part of the Igor distribution. So each release is distinguished only by the Bnn part of the file name.
2) The release notes for each release indicate the bugs fixed in each release, so viewers should be able to see each release. But I don't want them to download earlier releases. Can I disable the download for the early releases?
3) It would be nice if there were a way to subscribe to projects to be notified when a new release is posted. Particularly in my case, I want my beta testers to get the latest release so they are testing the latest code.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
January 15, 2008 at 11:06 am - Permalink
I am facing these same issues as I fix and tweak some of my packages and then repost them to the repository. Most of my mistakes are being made because I have yet to get my head completely around the concepts of trunk, tags, and branches as well as to understand how best to use the automatic package creation and versioning system in place on IgorExchange to my (and my package user's) advantage. As I learn more, I am being prompted toward writting additions for the documentation on the IgorExchange site. In the meantime, some things about the SVN operation might be better.
Why not create incremental development branches rather than incremental release tags?
Alternatively, create one primary development branch and create one development release from it. Point your working copy to the development branch. In such cases, each time you do a commit of the working copy to the branch, the overnight rebuild of the associated development release will update from the newly updated branch HOWEVER ITS VERSION NUMBER WILL NOT CHANGE (only its Last Update Time)!!! When your users want the newest version of a primary version of your package, they have only to download from ONE development release location (the one with the same primary release version number).
When you are happy with all the bug fixes in the working copy, commit everything to the branch, create a new release tag from the branch, create a new development branch from the branch, and viola, repeat the development process at the new release version.
Basically, this is all based on my understanding that, contents of a ...
Development Version (in a branches directory) are AUTOMATICALLY UPDATED NIGHTLY according to the contents of its original source (which appears under the rubrik ... Nightly development snapshot from CVS branch: ... when you View All Releases for the project)
while contents of a ...
Release Version (in a tags directory) are FROZEN based on the contents of ... Official release from CVS tag:
I too would like to be able to disable the showing of multiple (and long since dead) releases, especially after having made so many administrative mistakes in naming them in the first place. Ideally, I'd like to select exactly which releases can be shown to other people when they view in the development or release list. In an even further show of brashness, I'd want to have superuser privileges to kill my own monsters :-)
Ditto! I think Adam said, this is an as yet unrealized potential of the site.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 16, 2008 at 04:35 pm - Permalink
I have changed the tables to show only the default release associated with each Igor version. There are instructions for how to change the default major version associated with each Igor Pro version at http://www.igorexchange.com/node/78#releases.
I forget why I had originally chosen to display all releases, but I am guessing that you, Jeff, or Andy will soon remind me with a bug report or feature request. If you're not using Subversion for your releases (and John is not for this package, at the moment), I don't think you're likely to run into any problems with this change.
It is not possible for a non-admin to delete or remove a release once it's been added to the site, and I think that's for a good reason. From time to time it may be useful to be able to download a previous version, often to determine if a new version introduces a bug that was not present in a previous version. Users will still be able to view all releases of a project by clicking the View all releases link under the project download table. This should help to cut down on users downloading the wrong version.
As an aside, I recommend that when you post links on other sites or in email lists that you not give links to the release nodes or files themselves. Instead, give a link to the project overview page (such as http://www.igorexchange.com/project/Multipeak_Fit_2_Beta). That way the user is most likely to download the most recent version.
See also my response above. I can manually delete releases if you really want me to, but that will delete the release notes as well. If users downloading the wrong version continues to be a major problem please let me know, and I'll see if I can come up with a system that perhaps puts a "Warning: This release is not the most recent version." or something like that. I'm not sure how easy this will be to do, so I'd rather not find out unless it's really necessary :)
I totally agree with this. However, solving this problem is not as simple as it sounds. As Jeff mentioned above, email subscription to project updates is on my to do list. Ultimately, I would like to have some sort of status information from within Igor itself that would discover all Igor Exchange projects in use at the time and alert the user if there were updates available to any of the versions. For this to work, Igor would need to be able to retrieve data via some protocol (ideally HTTP). It might be possible to do this via FTP, which Igor currently does support, but I think it would be quite a bit more difficult. Jim mentioned the possibility of Igor being to do web transactions some time ago, but as far as I know this has yet to be implemented.
January 16, 2008 at 06:28 pm - Permalink
John isn't using the Igor Exchange subversion repository for this project, so that won't work.
Jeff, what you wrote above is correct. The one caveat with using a development release / subversion branch in this way is that you need to make sure that your package is functional each time you commit code to the repository. Some people make commits even when the code is not working properly. If someone does that and a user then downloads the code from a development snapshot, they could get a package that doesn't work.
The other difficulty with doing this is that it's difficult for the developer (John) to know exactly what state the code of the user is in at any given time. With official releases, it's clear what's in the code because the user can state a specific version number, instead of just a certain development snapshot.
In situations where many developers are working on code, it makes sense to have development snapshots. However, in a situation like this where John is really the only person doing developing, creating a new release for each beta release also makes sense.
I'm hesitant to allow deleting releases for a few reasons. One of the major ones is that on drupal.org, releases are *never* deleted. Since the modules that run the project management here are also those used on drupal.org, my guess is that there could possibly be nasty but difficult to find bugs that show themselves when releases are deleted, since this code is probably not tested as thoroughly since there is less need for it. Also, from a historical standpoint, I think it's best not to delete such things.
However, if you really want me to unpublish a release (which, from the users standpoint, is the same as deleting it), please send me an email with the URL of each release you want me to unpublish. As I mentioned above, this will hide the release itself as well as the release notes. However, the file created with the release will *not* be deleted. That's why I advised John above not to distribute the actual URL of files themselves.
January 16, 2008 at 06:44 pm - Permalink
Thanks for the prompt and detailed response.
My desire to be superuser is tongue-in-check. Your ongoing efforts at keeping up with the growing site useage are appreciated, and I look forward to having fewer problems to request be fixed as I finally determine exactly how I should be working with SVN.
As for fixing previous mistakes, I am now discovering how to hide "broken" release versions. Perhaps a suggestion along this line, in the table that allows one to set a minor release version option on packages with major release versions, an input of "-" could be used to denote "NONE" (ie, hide all versions of this release from being displayed). This would also mean, any newly created major release would always initially have two options for its minor release to display, "-" for NONE (do not display it yet) and its current minor release number.
Just my thoughts.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 16, 2008 at 09:32 pm - Permalink
I'm not sure which table you mean. Are you talking about the one at http://www.igorexchange.com/node/215/edit/releases (Note: Only jjweimer will be able to follow this link)? If not, can you provide a URL with such table.
BTW, I noticed some strange things with one of your projects (http://www.igorexchange.com/project/udFLStandardStructure). I'm guessing that initially this was not using Subversion, and that at some point you switched to using subversion with it. You have two releases, both official, but one of them is named IGOR.6.02.x-1.0.6-dev, which I think is confusing. This release also has a larger version number than the most recent release, IGOR.6.03.x-1.0. Is there a reason for this? Just curious. Maybe this is one of the cases where you would like to be able to delete a release?
January 17, 2008 at 04:06 am - Permalink
Yes. This table would IMO be a perfect place for a developer to be able to turn off or on the display of specific release sub-versions, much as one can disable the display of development versions.
Yes. My first few projects did not use SVN. Now (with one exception), they all do (and will). As for the confusion in version numbers in this specific case, it is due to my (still somewhat) limited (but continually improving) understanding about the best way to use version numbering in association with SVN on the site. In this case, I am banking on 6.02 being lower than 6.03, on the differences in release dates, and on the fuller explainations in the Release Notes as ways to define that 1.0 is actually AFTER 1.0.6-dev (ie, 6.03 is AFTER 6.02). And yes indeed, this would be an example of where the ability to "turn off" display of a release would be helpful. An even better example is here, where I actually show an earlier sub-release (2 rather than 3) of a full release, and while 2.1.2 is AFTER 1.0, 6.03-1.0 is AFTER 6.02-2.1.2.
Of course, with a fuller understanding of SVN and versioning system here, I would have avoided this mix-up altogether. But hindsight is 20/20, and kicking the heck out of the tires on a beta site release is what it's all about.
Thanks!
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 17, 2008 at 05:44 am - Permalink
I believe you'll be able to do this fairly soon. There is currently an issue for the project module which will greatly increase the control a project maintainer has with respect to indicating supported and recommended versions of a project. For a mockup of how this looks for a drupal.org project, see http://drupal.org/files/issues/project_203313_js_C_update.png
January 17, 2008 at 06:33 am - Permalink
What I really want is to simply remove the DOWNLOAD link next to outdated beta releases. I don't want to remove them, delete them from the site, etc. Just remove the link. In fact, I want the releases to show because I have listed bug fixes in the Release Notes section of the project.
I reviewed my posting on the Igor Mailing List and found that I had, in fact, given out a URL to the main project node. So that wasn't the problem. I think people just got to the site and downloaded the first thing in the list.
How about listing the releases with the most recent at the top?
Perhaps part of what I need is provided by the SVN module, but I wasn't going to go to that much trouble for a temporary beta :)
I guess part of what I'm doing wrong is in the version numbering- I should just give up and make my releases 2.00, 2.01, etc. When I release it I will close this project and release the package with Igor as 2.00. I'm in a special position, since my release will be part of Igor's official distribution.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
January 17, 2008 at 09:05 am - Permalink
Beautiful! This is much more than one can expect.
I think the issue that Adam references will handle your need as well, basically by allowing you to hide the listing of versions that are that are "outdated". I agree however, the project list should show releases with the most recent by DATE at the TOP.
Also, based on my still growing experience with SVN, it might have been useful for your desired approach. You can keep a development version fixed at 2.00, drop updates into the appropriate branch for automatic re-compiling, and build the SVN release keyword directly into your code to track the progress of the beta updates. The users will always only see one version of the package, and it will always point to the most recently updated release version. I have something like this started with SpXZeigR. If you're interested in knowing further about it, contact me off-line.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 17, 2008 at 01:11 pm - Permalink
Yes, indeed, this will help a lot.
Right- I was being lazy and trying to avoid the effort of the SVN stuff :) Especially as I have a mix of XOP, procedure files, help file, etc. I know I can check any of those things into an SVN repository, but...
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
January 21, 2008 at 11:04 am - Permalink
Time to Split Forums?
I think the Forums section is maturing to the point where it could be split, especially to allow further refinement of topics in IgorExchange and Igor Pro: Feature Requests.
- General Discussion
- Feature Requests
- Bug Reports
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
January 23, 2008 at 01:21 pm - Permalink
Oh- I just figured out that the second one gives me a couple of added options. Is this intentional?
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
April 3, 2008 at 12:41 pm - Permalink
John
I had not noticed that. Thanks for pointing it out. I've fixed the problem.
April 3, 2008 at 02:05 pm - Permalink
I've added a bit about this to the IgorExchange documentation on branches and tags.
--- OOOPS! NEVER MIND!
For some reason, this happened when the tag directory was first created and the file was not yet compiled for download. However, after it was compiled for download, the order was corrected.
I've re-modified the comments in the documentation.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
April 7, 2008 at 06:27 am - Permalink
In the future, I'd recommend not using the "extra identifier" field, especially unless you're adding some text there (like beta1, etc.). The newest version of the project display code, which is not currently being used on IgorExchange.com, does some funny things with ordering releases when the extra field is filled in. If you need it then use it, but if increasing the patch level by 1 is sufficient I'd do that instead. There's no need to modify the documentation about this yet, since it might not be an issue by the time I deploy this code, but I just thought I'd point it out to you.
April 7, 2008 at 08:42 am - Permalink
... I used the "extra identifier" on the Multipeak Fit 2 beta so that I could give each release a beta number. I want the version to be 2.0.0 so that when I ship the package with Igor it will be clear that 2.0.0 release is the follow-on to 2.0.0 beta N.
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
April 7, 2008 at 05:07 pm - Permalink
Yep, I know. That's one of the primary reasons I haven't deployed these changes yet. The new code really should handle such cases more gracefully, and since there's no real rush to deploy the new code I'll probably wait until I get handling of betas, RCs, etc. finished.
April 7, 2008 at 06:22 pm - Permalink
Renaming Projects?
Out of curiosity, before I attempt anything that will cause a breakdown ...
I have a project originally called "My Foo Bar" that I have renamed to "Foo Bar". What happens if I change the SVN package name from "MyFooBar" to "FooBar"? In particular, is the old SVN package directory "renamed" or is a new (empty) SVN package directory created? Alternatively, can I even do this as a user?
The specific project in this case is here, renamed from DeveloperPanel to Procedure File Manager Panel (because the new name makes more sense). I would correspondingly want to change the SVN package from CodeDeveloperPanel to PFManagerPanel.
Thanks!
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
June 5, 2008 at 10:10 am - Permalink
Suggestions for Adjustments to Frame Placements/Behavior
As project and forum lists get longer, scrolling the window back to the top to access menu commands can be cumbersome. As a user scrolls the right frame down, having the left menu selections stay "floating" as well as the top menu bar stay always resident would be helpful.
(Firefox on Windows Vista ....)
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
June 5, 2008 at 10:17 am - Permalink
You're treading into untested territory, as far as the scripts on this site go. I haven't tested out this case, so I can't say for sure how things would work. However, if you're determined to do this, I think you'd want to do the following:
svn move svn://svn.igorexchange.com/packages/CodeDeveloperPanel/ svn://svn.igorexchange.com/packages/PFManagerPanel/After you do this, I'm not sure how the packaging scripts will handle the renamed stuff. Hopefully they would rebuild the zip files attached to your release nodes. I think I'll have to manually change the titles of the release nodes, however, since you probably won't be able to do that yourself.
If you go through with this and run into difficulties and/or need additional help from me, please just contact me directly.
June 5, 2008 at 04:04 pm - Permalink
Personally, I find this kind of behavior on web sites highly annoying, so my initial reaction is to not do this. In addition, I believe that this would need to be done in javascript, and the level of my javascript knowledge approaches zero. There might be a built in method in the jQuery library that Drupal uses that can do this, but I haven't looked. I just tend to use the home and end keys to move to the top and bottom of a page very quickly. But I'll keep this idea in mind and think about implementing it if it's relatively easy.
June 5, 2008 at 04:07 pm - Permalink
My level of javascript programming may be slightly greater but still likely insufficient.
OTOH, I have done such left and top static menu placements using FRAMES and find them relatively easy to set up. It requires a proper target directive to send content to the correct frame. Would a sample be of interest?
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
June 7, 2008 at 07:05 pm - Permalink
Let's hold off for now. I want to try to make some of the pages a bit shorter so there is less need for this kind of thing in the first place. I have also found that even seemingly minor changes to the theme end up taking a lot of time, partially to the differences in how different browsers render stuff. Once we upgrade to Drupal 6, which won't be super soon but should happen at least by the end of this year, we'll have a much newer version of the jQuery library to use and there might be something like this built in. I might consider allowing users to select between two themes, one which has automatically moving menus and one which does not.
June 8, 2008 at 07:42 am - Permalink
Thanks
Adam
June 8, 2008 at 07:44 am - Permalink