X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 13 Sep 2007 14:27:03 -0400 (EDT) From: Igor Peshansky Reply-To: cygwin AT cygwin DOT com To: Lewis Hyatt cc: cygwin AT cygwin DOT com Subject: Re: setup.exe suggestion + patch In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Thu, 6 Sep 2007, Lewis Hyatt wrote: > Hello- > > Firstly, thanks to everyone who has worked on setup.exe, it's really a > very convenient program! There is just one thing that has always > bothered me, which is that you have to click repeatedly on the package > or category to cycle through all the available actions to find the one > you want. The main problem is that each click causes the dependencies to > be recalculated, which can cause annoying slowdowns if you're trying to > do something like uninstall all packages in a large category. There is > also the following situation which occurs often, especially when you are > playing around with installing and uninstalling new packages: > > -package A requires package B > -package A has two available versions > -package B appears before package A in the list > > Now suppose A and B are both installed, and you want to uninstall them. > Since B appears first, you click through to uninstall, no problem. Now > you scroll down, maybe several pages away, and try to uninstall package > A. The first time you click, though, you end up on the Prev version, > which then calculates that it needs package A and goes back and sets > package A to Install again. The only way to uninstall both of them is to > uninstall B first, and then A. When there are multiple dependencies > involved, it can quickly get impossible to get setup to do what you > want. > > The simplest way I could think of to correct this would be to change the > behavior so that when you click on a Category or a Package, instead of > simply cycling through, you get a little popup menu that asks you what > you want to do instead. This way, you can go directly to Uninstall > without dealing with the intervening options. This also lets you see all > available versions at once, and avoids calculating dependencies > unnecessarily. > > I wrote a simple patch that implements this suggestion. Attached are the > outputs of cvs diff (in diff.txt) and cvs diff -n (in diff_n.txt). (I'm > sorry, I don't know much about CVS, is this the preferred way to submit > a patch?). Here is a summary of the changes: > > -Created new class PopupMenu in PopupMenu.{h,cc}, which makes a popup > menu at the mouse cursor location and returns the selected item. > > -Added #define to resource.h for use by PopupMenu. For now, it just > reserves 100 IDs, supporting arbitrary popup menus with up to 100 > entries. (The number 100 is easily configurable in resource.h.) > > -Modified PickCategoryLine to open the menu instead of cycling. > > -Added new function select_action() to the packagemeta class, which > implements the menu selection. For now, this is done in an extremely > quick and dirty way that simple calls set_action() repeatedly to figure > out which options would have been cycled through. I would be willing to > re-do this in a more efficient way if this patch is deemed useful, but I > don't even think that's necessary, I think it's fine to do it this way > which reuses the already bug-tested code in set_action(). > > -Modified PickPackageLine to call select_action() instead of > set_action() when the line is clicked. > > -Made some minor changes to packagemeta::_action to expose the category > strings as part of the public interface, so they could be reused in the > popup menu. > > Anyway I hope this is useful, if this patch isn't acceptable please let > me know and I can fix it or change it. I wasn't sure about conventions > with tabs, line endings, line lengths, etc., for one thing. In general, > I think the problem I have described requires fixing. If you don't think > this solution is an improvement, I can look into fixing it a different > way also. First off, thank you for the popup menu implementation -- I was planning to use it for something else in setup, and now I don't have to write it. Second, I agree that the problem is good, and I like your solution of selection vs. cycling. Third, I have to apologize -- I've had a partial reply to your message sitting in my drafts since the day you sent it, but got bogged down. A few comments on the patch: 1) It would be great if you used "diff -up" -- unified diffs are so much easier to read. 2) Is there a reason you use popup menus, rather than pull-down lists? 3) [Minor] You'd use the GNU coding guidelines for whitespace and indentation. If you could resend a unified diff, I'll apply it in my tree and test it out. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/