GSOC09 MacPorts GUI
armahg at gmail.com
Fri Jul 10 19:55:33 PDT 2009
I was hoping Juan would have replied by now. He sent me an email and we are
scheduling a fixed time to meet that works for both of us since his internet
at home is still down. The good news is that he can still work from an
> 1) Do you plan to support categories? Ports list categories that they
> belong to, so it would be nice to have a browsing option that allows us to
> "expand" categories.
The framework has that information. I also asked Juan to layout the UI so
that the main port list can easily be resized to accommodate a port category
list view on the left - kind of like in Finder. Clicking on each category
will filter the current port list to ports from just those categories. If
there is time we will work on implementing this.
2) How are variants handled? Do you have a gui way to edit
> $prefix/etc/macports/variants.conf? What about per-port variants at install
The framework also exposes them but currently they are not exposed in the
GUI. I am not sure about editing variants.conf but per-port variants at
install time is certainly doable. We just have to figure out a reasonable UI
> 3) You said, "I’m working into getting that separate process to be part of
> the Framework and also make it send notifications back to the Framework to
> know the progress of the port command being run." ... I'm curious what level
> or notification you are designing. It would probably be nice to have a
> window that shows a general progress bar for the current port/stage... but
> for debugging purposes, it would be helpful if this could be expanded via
> "Details" button or similar to show the verbose or debug output.
The current design uses distributed objects to send messages from the port
process to the Framework. The GUI has access to these messages from the
Framework. Setting the verbose level is also possible using the Framework.
We are planning to display a progress bar at the very least. A window with
the log details should be fairly easy to do since we get all those messages.
I have asked Juan to speak to the other GSoC student to see if any of his
GSoC work would benefit us in this regard.
> 4) Do you plan to have a preferences interface to common
> $prefix/etc/macports/macports.conf options?
We will need some help implementing this since I am not familiar with the
macports.conf file / modifying its preferences etc. If it is one of the
files the Tcl interpreter loads before performing port operations, and is
modifiable via Macports Tcl commands then it should fairly easy to do.
I'll discuss the above with Juan and ask him to contact you with some more
questions. Our goal right now is to have a functional, non-buggy GUI that
performs all the basic port functions and can be easily extended with
advanced features. I think we will have time to implement some of the above
Thanks for the feedback!
> On Jul 7, 2009, at 12:17, Juan Germán Castañeda Echevarria wrote:
> Hi everyone,
>> I’ve been very busy these days working in the GUI, I’ve learnt a lot of
>> things and first of all I want to thank my mentor, Georg Armah, for
>> me a lot of things and being so patient with me. Also I’d like to thank
>> the other mentors that have helped me on IRC (I should do that more!).
>> Current Status
>> Now is the time to introduce you my work. I’ve done the first version of
>> MacPorts GUI application and this is what I have:
>> - Support for non-default MacPorts installation locations. (Via the
>> Preferences window)
>> - Basic and Advanced Search (currently can only search by port name and
>> status, but this is easily extendible)
>> - Install, Uninstall, Upgrade port operations in background
>> - Sync and SelfUpdate in background
>> What doesn’t work:
>> - Status field in ports table doesn’t change after install, uninstall and
>> What still needs to be implemented:
>> - Make the Framework use a separate process to perform port commands (see
>> the Problems section below)
>> - Port info. This will be displayed like a quick look window.
>> - Progress notifications and cancel command. I’m thinking in having this
>> as a activity window (Something like Safari’s downloads window) and allow
>> the user to queue port commands to perform then sequentially.
>> To install it from source, you only have to checkout the gsoc09-gui
>> and build the MPGUI Xcode project with the Debug-InstallMacPorts
>> svn co http://svn.macports.org/repository/macports/branches/gsoc09-gui
>> That will build the MacPorts.framework, a MacPorts 1.8 unprivileged
>> installation and selfupdate it.
>> I also have included a binary version that should work out of the box. To
>> make it work I embedded the Framework in the application bundle but we
>> planned that the Framework will be installed separately form the
>> and will live in a Frameworks directory (in /Library or the per user
>> The first time the application is run, the preferences window will come
>> and you should set the Tcl installation path. Since the GUI is tested with
>> MacPorts 1.8, you can set it to the macports1.8/Library/Tcl directory
>> created in the build directory if you built it from source. If you’re
>> the binary version you can install an unprivileged macports (from trunk),
>> selfupdate it and test with it or use your /Library/Tcl installation (this
>> will work partially).
>> Since I'm having problems with my internet connection I haven't tested it
>> thoroughly, so If you encounter any problem, please let me know.
>> The main problem has been the multithreaded implementation because for
>> reason (it is very difficult to debug) the destroot phase was interrupted
>> and the thread died when installing some ports (expat, libiconv, pngcrush,
>> …) that use xinstall with the ‘-W’ flag. After doing some tests we found
>> that when the port command was run in another process rather than in a
>> secondary thread, it was smoothly completed.
>> Then we opted to create a separate process to handle port commands and
>> the GUI to communicate with it via distributed objects messaging. This is
>> the version you’ll test.
>> Currently I’m working into getting that separate process to be part of the
>> Framework and also make it send notifications back to the Framework to
>> the progress of the port command being run. This way it will be more
>> transparent to the client (in this case the GUI, but it could be something
>> else) and the GUI implementation will be simpler.
>> Final thoughts
>> I hope to get a lot of feedback from you regarding the interface design
>> also about how it is working now. I’m working to get a new version of the
>> Framework with the changes I explained in previous paragraphs by the
>> beginning of the next week.
>> Ash Mac durbatulûk, ash Mac gimbatul, ash Mac thrakatulûk agh burzum-ishi
>> Juanger. http://xocoruby.blogspot.com
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
> macports-dev mailing list
> macports-dev at lists.macosforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev