On 28/02/13 18:26, David Gressett wrote:
> Suggestions for minor improvements:
Thanks for this positive critique, David. It's much appreciated.
> 1. When doing an Update Catalogue from the Installation menu, a box
> appears that tracks the catalogue items, displaying them with an item
> countdown so that progress can be easily seen. It would be nice if
> the countdown could be displayed separately from the displayed item
> name, so that it would stay in the same place in the box and not
> bounce around as the download progresses.
It's currently implemented as a snprintf() to format the text, followed
by a SendMessage() to copy it to a static control within the dialogue
box. You'll see the same text format in messages from the CLI, (with
matching version), when you run "mingw-get update".
I can certainly explore the feasibility of implementing something along
the lines you suggest; however, I want to avoid unnecessary complexity,
while still maintaining consistency between CLI and GUI clients. If I
do pursue this, I won't be assigning a particularly high priority.
> 2. When installing items selected for upgrade or install from the
> package list, there is also a progress box displayed, but it does not
> display an item countdown, which would be nice to have.
Uses the same dialogue box template, but controlled from a different
area of the code. I'm sure there's a way to implement this, but as a
"nice to have", it will attract low priority.
> 3. It would nice to have check boxes in the menu bar to selectively
> turn off display of mingw or msys packages. With this, I could hide
> all of the mingw packages and bring the msys stuff to the top of the
I already plan to implement an alternative (IMO better) solution:
That tall, mostly empty pane at the left of the window, which just says
"All Packages" right now, is actually a tree view. I plan to populate
it with "package category tags". The XML catalogues already define
package affiliations with (tentative proposals for) such tags. When any
of these tags is selected, in the tree view, the package list will be
filtered, to display only those packages which declare affiliation with
the selected tag, or any of its "children" within the tree.
Since "All Packages" represents the root of the tree, all other tags
will be "children" of it, so when it is selected, you will see the full
package list, as at present.
> 4. Another check box could be used to hide uninstalled packages.
IOW, filter the list to display only "installed" packages. Yes, I'll
consider this, as a logical extension of...
> 5. Still more check bixes could control display of items by class, so
> that I could, for example, display only doc packages.
...this. I'm already considering something similar, but since I've
written mingw-get to support arbitrary class names, and it would be
totally impractical to have an infinite collection of check boxes, I do
need to give some further thought to any implementation.
> Suggestions for nontrivial inprovements:
> One of the Installation menu items is "Mark All Upgrades" which I
> presume means to mark all packages which have upgrades available to
> be upgrded.
This is probably what you mean anyway: it identifies any of those
packages which you have installed, for which upgrades are available, and
marks them to be upgraded.
> I don't want to use anything like this, because I use the
> 4.6.2 version of the compilers and can't upgrade to the most recent
> compilers because I use non-Mingw Ada packages which do not work with
> the 4.7.2 Ada compiler.
I appreciate that you have a special requirement here; it would also
preclude your use of the existing "mingw-get upgrade" CLI capability,
when specified without package name arguments, to upgrade the entire
installation. The GUI could be less destructive for you, in this case,
since it only *marks*, pending your further instruction to "apply",
whereas the CLI does mark and apply in one fell swoop. With the GUI,
you could "Mark All Upgrades", then "Apply Changes" to review the
upgrade plan; (it won't actually apply anything, until you confirm
permission to proceed). If you see any planned upgrades that you don't
want to accept, you can "Defer" the "Apply Changes" dialogue, "Unmark"
any packages you don't want to upgrade, then return to "Apply Changes",
to confirm the "Apply" action.
> It would be nice to have a way to lock a
> package and its related packages against a Mark All Upgrades, so that
> I couldn't accidentally mark all of the 4.6.2 stuff for upgrade
> because I selected a spiffy new package for installation which had a
> sneaky 4.7.2 compiler dependency in it.
I agree that this is desirable -- even necessary; it is on my to-do list
for implementation, with moderate to high priority.
> There doesn't seem to be a way to specify a package downgrade, as can
> be done with the command-line mingw-get.
Also on the to-do list; for the time being, you still need to use the
CLI for this feature.
> It would be nice if the
> items in the "Repository Version" column were dropdown lists, with
> the most recent version number displayed by default. I could then
> select an older version by clicking on a small down-arrow at the
> right edge of the entry and picking the appropriate older item. The
> dependency-checking routines would then update other related packages
> to display the versions consistent with the downgrade.
It may be possible to implement it like that, but I suspect it would
incur a level of coding complexity that I'd rather avoid. I'll bear it
in mind, when I get to actually implementing such a feature.
> With this in
> place, I could take a MinGW installation with the 4.7.2 compilers in
> it, change only one 4.7.2 item to 4.6.2 and downgrade the whole lot
> with very little effort.
Can't you already do this, via the CLI? I know it isn't perfect, and I
will be giving a high priority to making this aspect more robust, after
I have gotten as far as a release candidate for the GUI. This feature
is implemented within mingw-get-0.dll, which provides a common back-end
to both the CLI and the GUI; if it already works in the CLI, it should
also work, when an appropriate interface is implemented in the GUI.
> If s package has only one version available for installation, there
> should be no down arrow, so that such items could be easily
> identified at a glace.
You'll be able to see this, probably more visibly, on the "Versions" tab
in the lower right-hand pane, when I get that populated.
> The Installed Version column could also profit from drop-down lists;
> these could be used to manage items which allow concurrent
> installaten of different versions. The down-arrow should not appear
> for items which allow only one version, or if only one version is
> installed for items which allow multiple versions.
Another aspect which needs priority attention. I'll formalise an
implementation, when I get a round tuit.