Hi guys,
Attached is a pure-text file (made with vi), containing my ideas so far
for a new MacPorts GUI. Comments, suggestions and reviews are
welcome.
It is intended to be a simple tool for first-time users (in Basic mode)
and a more versatile tool for more advanced users (in Advanced
mode) to browse the huge amount of information stored in MacPorts.
Fossick is a working title for the GUI --- as explained in the attached.
I have been slowly getting to grips with Xcode 4.6, Cocoa, the
Interface Builder and Objective C in the last few weeks. It
certainly has a different philosophy from Qt and C++.
A rough prototype layout is now running. It can load and search
all the ports, but needs more menus and toolbar items and the
functionality that goes with them. The screenshot is 160 Kbytes.
Should I attach it?
I have also worked out a scheme to launch "port" commands in
the background and monitor the output, requesting an admin
password in the usual Apple OS X popup, when required.
BTW none of the above uses Macports Framework. It works directly
with the port index file and the "port" command. IMHO that will
provide a more stable interface than MacPorts Framework, long-term,
and its speed is adequate.
The main window has three panes: top, bottom left and bottom
right, all of which are resizable within the overall window size.
The top pane is a table view of all ports or all those found by the
most recent search (case-insensitive) of name and description and
(optionally) a category. There will probably also be a way to
select installation statuses (analogous to "port installed", etc.).
The bottom two panes will run a more advanced search, monitor
the output from a background run of "port" commands or provide
various kinds of information about ports clicked on and selected
in the top pane.
Please have a look and send your comments.
All the best, Ian W.
FOSSICK - Specification for a MacPorts GUI
------------------------------------------
Fossick is an Australian word for free, unlicensed exploring of a mine site.
Some fossickers have been known to find valuable gold nuggets, even in recent
years. "Fossick" also begins with the letters FOSS, so it contains the idea of
searching for and finding Free Open Source Software.
Target Users
------------
1. People who have just bought their first Apple Mac.
2. People who have used a Mac for some time, but have not encountered OS X
"up close" or are not aware of FOSS (Free Open Source Software) available
on the Mac.
3. Users of FOSS on the Mac who would prefer to use a GUI or at least have a
simplified way of installing and updating FOSS.
4. Expert users of FOSS and MacPorts who would like an alternative tool to
explore the huge amount of information available in a MacPorts environment
(16,000+ ports and counting).
Objectives
----------
1. Make it easy for user groups 1 and 2 to install, update or uninstall the
basic provider software such as MacPorts itself.
2. Make it easy to find FOSS that a particular user might find interesting,
especially users in groups 1 and 2.
3. Make it easy to install, update and keep track of selected FOSS in the
user's system.
4. Avoid surprises and uncertainty involving long installation times.
5. When an installation or update fails, make it easy for the user to gather
and report the necessary diagnostic information and to recover to a
pre-installation state --- maybe even to attempt to diagnose the problem
him/herself.
6. During an installation or update, provide a selectable level of detail re
what is happening.
7. Spend less time on handling tickets and mailing list queries (see 5 above).
Requirements
------------
1. For each FOSS provider (initially only MacPorts), retrieve a complete list
of all software items provided and their attributes.
2. Make the list of items selectable and filterable by a range of attributes
and values, similar to what is possible in MacPorts commands, but possibly
including an additional list of "root" items on which no other items depend.
3. Display retrieved lists in table form, with name, installation status,
version, short description, categories and variants of each item.
4. Provide a one-click display of full details (as in "port info") for any
item in in the table view.
5. For Basic user mode, provide a default search method and basic information
on each software item (e.g. info, dependencies and home page).
6. For Advanced user mode, provide an advanced search method and a full range
of information on each software item (e.g. portfiles, contents, etc.).
7. Provide menu/toolbar actions for install, upgrade, uninstall, etc. for any
item in the table view, putting the required action in a list or queue of
actions to be performed.
8. Analyse the dependencies and dependency actions implied by an action, before
it is run, and warn the user if the total number of actions exceeds a limit
set by Preferences and so the run could take a long time.
9. When the user signals he/she is ready, perform the collected list of
actions in background mode, first soliciting a password if required.
10. Collect and store all output from a background run, in case anything goes
wrong later.
11. Progressively display the results of a background run at a selectable level
of detail, of which the least detailed would be "<action><item><status>",
e.g. "install inkscape DONE", "installing inkscape - step 6/13 - libpng",
"install inkscape FAILED - step 7/13 - poppler".
12. If a run failed, provide options to see more detail of the output, report
a problem or generate a proforma of an email to a mailing list.
13. If there are notes or post-installation actions for a software item, collect
them and display them at the end of the run.
14. Keep a history of previous installation actions, dates and times.
15. Save preferences and selections from a previous Fossick session.
16. In saved selections, include the last-used filter and sort-order.
17. In saved preferences, include at least the following:-
- Whether to run the GUI in Basic or Advanced user mode (default Basic).
- The number of dependencies that triggers a warning (default 10).
- The preferred level of detail in output from installation runs
(default is minimal detail).
- The number of previous versions of an installed software item to keep
as deactivated, not including the provider's revisions, which should
be automatically superseded (default 1).
- Default filters selected by the user (e.g. Python, games).
- The set of table-columns to be displayed/hidden.
- Options dependent on the provider (initially MacPorts only).
18. Support staged installation when there are many dependencies (e.g. qt4-mac,
then kdelibs4, then digikam or other KDE apps the user requires).
19. If possible, allow the GUI to be terminated, with a warning, when a
background run is in progress, letting the background run continue.
20. If possible, allow background run results to be picked up and displayed by a
later run of the GUI application.
21. If possible, allow the GUI application to abort a background run.
22. Provide a cleanup function for a background run that has failed or been
terminated prematurely for any reason at all. This needs to be AFTER any
error handling actions (see 10 above).
23. Provide functions to install, uninstall and update the provider's own
software (initially only MacPorts and its ports info).
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
