Hello Kevin, On 21/04/2013, at 4:28 AM, Kevin Walzer wrote: > I'm the competition here (http://www.codebykevin.com/portauthority.html), but > since no one else has provided any comments yet, I'll offer a few.
Thank you for being so chivalrous as to review my code. > The app felt very sluggish the first time I ran it in Xcode--I wasn't sure if > this was because of the overhead of running it under Xcode or what. It was a > bit snappier when I closed Xcode and ran it separately. I find that every morning after booting up. I think it is an Xcode startup overhead. The first compile and run goes slowly, subsequent runs are faster. The Console app output indicates that Fossick itself takes about 3-4 secs to get going. > From a design standpoint, the UI is a bit counterintuitive. I understand the > idea behind the side-by-side text views, but it strikes me as fiddly and very > much out of step with the customary two- and three-pane interfaces that are > prevalent today: table view, tree view, text view. My solution is to have all > data in a single text view; there may be other ways to do it, such as a > floating window, etc. But I didn't grok the purpose of the twin text views > until I read the "readme." You can't assume users will do that. I thought about a sidebar, but could not see a use for one. The list of ports is essentially unstructured and subject to filtering, sorting, etc. The twin subviews idea arose because there was wasted space down there once I had all the columns in the table view and there was room for another view. Actually I find side-by-side views quite useful, putting on my MacPorts end-user hat … :-) > I also noticed that changes in MacPorts were not reflected in the app after > running an operation. For instance, I selected a random port (gawk) and > installed it. It did not change state in the table view after the port was > installed (i.e. was not listed as being installed). It did not show up as > installed until I re-launched the app. That's a fairly significant issue; > users will wonder if anything happened if they do not see changes in the UI > that reflect operations they have run. Please have a look at the FossickSpec.txt file. The "install" was the last bit I got working. My intention is to complete it by automatically opening a subview to Results Of Run and afterwards to update the status. For beginning users, Results Of Run will be filtered to show overal success or failure only, plus progress through the dependencies. It would be nice if I coud find a way to do time estimates as well. > In a similar vein, the app provides no visual feedback of an operation > running. No scrolling text in the text view, not even a progress bar. I ran > an install command and the app just sat there. A user should not have to > select "view output of operation" from a tiny little popup menu to get an > indication of what is happening. See above. I will probably have some kind of indicator(s) that something is going on in the background even if Results of Run is deselected. > It appears you're handing a lot of the operations off to AppleScript to > actually execute port commands, via the "do shell script" paradigm? That's an > interesting choice. It solves the problem of running privileged operations > without having to delve into the authorization libraries, but doesn't it run > the risk of locking up the app? AppleScript blocks until a command is > returned. (Wranging with this very dilemma years ago, I finally ran across a > different solution, whereby a user password is echoed is piped to "sudo port > install" or what not.) I'm curious how you keep the app responsive while you > have this massive blocking operation going on under the hood. Did NSTask not > provide useful tools for running port commands, or was there some other > reason for choosing AppleScript? See the method runPrivilegedScript in SoftwareActions.m. It is non-blocking. I also like using the "port" command method because it is fast enough and is fairly stable as MacPorts changes. Pallet, by contrast, uses libraries, but these are out of date now ... I use AppleScript to get the usual Apple authorisation behaviour. The command it runs has an "&" on the end, so it is non-blocking. I use an NSTask and "tail -f" to collect and display the output as it happens, rather than letting AppleScript show the whole lot at the end of the run. > Anyway, I realize this is an alpha of an alpha build, and there's still a lot > to be done, but some of what I'm responding to seems basic to the design > rather than something that will be smoothed out later, so I felt it would be > useful to raise these points. > Hope they're helpful, > Kevin Thank you, Kevin. Yes, it's very alpha, but I have very much appreciated your input. Cheers, Ian W. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
