Hi Juan,
That looks very promising. I'm excited about this work. I do have a
few questions.
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.
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
time?
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.
4) Do you plan to have a preferences interface to common $prefix/etc/
macports/macports.conf options?
Thanks,
Jeremy
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
teaching
me a lot of things and being so patient with me. Also I’d like to
thank all
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 the
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
upgrade.
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.
Installation
To install it from source, you only have to checkout the gsoc09-gui
branch,
and build the MPGUI Xcode project with the Debug-InstallMacPorts
configuration<http://www.screencast.com/users/juanger/folders/Jing/media/01000c79-6663-486f-81d7-6ce56d12366a
>
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 have
planned that the Framework will be installed separately form the
application
and will live in a Frameworks directory (in /Library or the per user
~/Library).
Running
The first time the application is run, the preferences window will
come out
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 using
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).
Screenshot<http://www.screencast.com/users/juanger/folders/Jing/media/dbc07263-fe93-4015-aeed-6341b589dafc
>
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.
Problems
The main problem has been the multithreaded implementation because
for some
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 made
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 know
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 and
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
krimpatul.
Juanger. http://xocoruby.blogspot.com
<MPGUI.zip>_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
