Folks -
I finally got around to do a quick mock-up of what I'm having in mind as UI for dealing with the Configurations package. If you want to try it do this: * Load the latest Configurations from the inbox * Load the ConfigBrowser from the inbox * Fire up ConfigBrowser via "ConfigBrowser open" What you'll find is something that looks suspiciously like the SqueakMap UI :-) which is no surprise since that was what I wanted. The goal is that we derive lots of useful information from the configurations itself, such as: - The category the config is in. The system category provides the top-level structuring in the browser. - The class comment. The configuration's class comment is utilized as the comment for the package itself. - Various config info. The list of available versions, the blessing status, the description of versions are all derived directly from the configuration. There's still a lot of things open and missing. First, this doesn't actually install anything yet :-) but then again it's a UI mock-up at this point to get some feedback. Also, there's no way to specify 'optional' installs. I'm starting to think that Metacello might be going down the wrong path with it's 'default group' usage - I think a group should have a 'default' attribute that indicates whether to include it in a default install. That way, we could actually provide a list of options to install (which is difficult currently because it's not clear whether the groups overlap or not). But I'll bring this up with Dale and we can see how to deal with that. In any case, that's kind of what I'm thinking of in terms of UI. If someone wants to hack along, please go right at it. This is 'work in progress' and by no means finished but I think it's good enough to see what I'm trying to do. Feedback welcome! Patches even more :-) Cheers, - Andreas |
Hi!
On 05/19/2010 07:44 AM, Andreas Raab wrote: > Feedback welcome! Patches even more :-) I haven't even looked yet - BUT... I got reminded by a nice "feature" in Lunar Linux's package management tools when you were discussing "default groups" etc. Perhaps I misunderstood - but I guess its about "questions to the user when installing stuff". Earlier Installer introduced (Keith IIRC) some mechanism to provide automatic answers to regular popup dialogs etc. A hack, but still. In Lunar Linux each module (=package) has a defined *list* of "options" with default answers. A typical such question is whether to install an optional "nice package" - in fact, those questions may be automatically derived from a list of "optional dependencies" - but whatever. When you perform an installation of a module the dependency system figures out the total list of packages to install - and then compiles a *complete* list of questions for all modules that it *will* install and then asks the user for their answers. Thus, when the install actually begins after the questions have been answered it is fully automatic and is nicely done "in the background". This also has the nice side effect that the user can "bail out" in the quesion phase if the user realizes that he/she does not know some of the answers. Have no idea if this was totally off subject. :) regards, Göran |
On 5/18/2010 11:35 PM, Göran Krampe wrote:
> On 05/19/2010 07:44 AM, Andreas Raab wrote: >> Feedback welcome! Patches even more :-) > > I haven't even looked yet - BUT... I got reminded by a nice "feature" in > Lunar Linux's package management tools when you were discussing "default > groups" etc. Perhaps I misunderstood - but I guess its about "questions > to the user when installing stuff". It's a little off. What I was referring to is that in Metacello you can define 'groups' of packages. I think the intent is that such groups are like installation options, e.g., something like Installing Foo: [x] Foo-Core (required group) [ ] Foo-Tests (optional group - unit tests) [ ] Foo-Help (optional group - documentation) The current Metacello definition is such that if it exists, the 'default' group is being installed. But that can only be a single group so in the case that I wanted to structure the above into three separate groups but by default have both Core and Tests selected I would have to create a separate default group for that. And that creates confusion because you can't really present that in a UI properly. What I'd like to see instead is something where we can define a little more of the status of these groups. For example: #required (for groups that must be installed), #default (for groups that are optional, but installed by default), and #optional (groups that are optional and not installed by default). The assumption being that the groups are largely non-overlapping sets of packages that I can independently select. But I have no idea how Dale intended this to be used so I'll have to wait until he can comment on this. > Earlier Installer introduced (Keith IIRC) some mechanism to provide > automatic answers to regular popup dialogs etc. A hack, but still. I think this may actually exist in Metacello. I've seen a 'supplyingAnswers:' part of the spec that smelled a lot like that very hack ;-) > When you perform an installation of a module the dependency system > figures out the total list of packages to install - and then compiles a > *complete* list of questions for all modules that it *will* install and > then asks the user for their answers. Thus, when the install actually > begins after the questions have been answered it is fully automatic and > is nicely done "in the background". Ah, interesting! Yeah, that's a pretty good idea. So basically the packages announce beforehand what info they need and later on just use these answers? Cheers, - Andreas |
On 05/19/2010 10:23 AM, Andreas Raab wrote:
> On 5/18/2010 11:35 PM, Göran Krampe wrote: >> When you perform an installation of a module the dependency system >> figures out the total list of packages to install - and then compiles a >> *complete* list of questions for all modules that it *will* install and >> then asks the user for their answers. Thus, when the install actually >> begins after the questions have been answered it is fully automatic and >> is nicely done "in the background". > > Ah, interesting! Yeah, that's a pretty good idea. So basically the > packages announce beforehand what info they need and later on just use > these answers? Yeah. Here is a page describing their system slightly more correctly than I did: http://wiki.lunar-linux.org/index.php/Module_Basics In general I really liked Lunar and its package management - probably quite similar to BSD ports and Gentoo portage etc, and I do think some lessons can easily be learned by looking a bit at them. One interesting trick that Lunar uses (and probably all source distros) is that when doing the "make install" (or whatever some tar ball wants to do) phase of a module installation, Lunar first installs low level filesystem "hooks" to capture ALL modifying file operations performed during that phase. This way Lunar always knows EXACTLY what files a certain module actually did install, and it can then uninstall it cleanly and keep track of where files "came from". Now... what would be our counter part? :) A recording Delta can capture all source modifications, and perhaps the Delta model could be extended with other "image modification types" like for example - "creation of a global" or "registry of a service" etc. Just thinking loud. :) regards, Göran |
In reply to this post by Andreas.Raab
The only thing I don't like about this is a design holdover from the SM Catalog gui: it tells me too much information that I don't actually want. I go to development and I click, and, Hey!, there's the OmniBrowser. That's just what I want! Then I click that, because I'm led by another pointer-arrow. I click that and now ... there are five OmniBrowsers. I don't want five. I'm an end user, not an OB developer. I want THE OB.
So now I have to scan this list, realize that the highest number is at the bottom (or not, in this mockup), and then suppose that that's the most recent. Select it and then load it. Cross my fingers, and suppose I've understood this interface. Meanwhile, I'm asking myself why the other, outdated, OBs are being given equal billing with the most recent version.
I have a book on web site design called Don't Make Me Think. This UI makes me have to think and then to guess. The whole direction of Metacello, it seems to me, is to lead people to a series of defaults, so they don't have to think.
I say bury older versions, and present only one version: THE OB, or THE WebClient. If people want to dig into the versions of OB from 1.0 to 1.1.2, then push it out of immediate site. Push it down a level in the hierarchy.
It's true. I don't lack for opinions. It's been said. :) Chris
|
On Wed, May 19, 2010 at 10:08 AM, Chris Cunnington
<[hidden email]> wrote: > I say bury older versions, and present only one version: THE OB, or THE > WebClient. If people want to dig into the versions of OB from 1.0 to 1.1.2, > then push it out of immediate site. Push it down a level in the hierarchy. > It's true. I don't lack for opinions. It's been said. :) I agree. In fact, I don't think that old versions should be in the image at all. People who want the old versions should go to the web site for the package. The image should just have the current version, and the browser should only show it. Otherwise, the system will just gather more and more cruft. -Ralph |
On 5/19/10, Ralph Johnson <[hidden email]> wrote:
> On Wed, May 19, 2010 at 10:08 AM, Chris Cunnington > <[hidden email]> wrote: > >> I say bury older versions, and present only one version: THE OB, or THE >> WebClient. If people want to dig into the versions of OB from 1.0 to >> 1.1.2, >> then push it out of immediate site. Push it down a level in the hierarchy. >> It's true. I don't lack for opinions. It's been said. :) > > I agree. In fact, I don't think that old versions should be in the > image at all. People who want the old versions should go to the web > site for the package. The image should just have the current version, > and the browser should only show it. Otherwise, the system will just > gather more and more cruft. > > -Ralph > > It should be easy to load. And the particular version should have been tested against the particular version of the image I'm actually working with. If I want more choice I can always go to check out the Metacello repository. --Hannes |
In reply to this post by Andreas.Raab
Andreas Raab wrote:
Andreas,On 5/18/2010 11:35 PM, Göran Krampe wrote:On 05/19/2010 07:44 AM, Andreas Raab wrote:Feedback welcome! Patches even more :-)I haven't even looked yet - BUT... I got reminded by a nice "feature" in Lunar Linux's package management tools when you were discussing "default groups" etc. Perhaps I misunderstood - but I guess its about "questions to the user when installing stuff".It's a little off. What I was referring to is that in Metacello you can define 'groups' of packages. I think the intent is that such groups are like installation options, e.g., something like Installing Foo: [x] Foo-Core (required group) [ ] Foo-Tests (optional group - unit tests) [ ] Foo-Help (optional group - documentation) The current Metacello definition is such that if it exists, the 'default' group is being installed. But that can only be a single group so in the case that I wanted to structure the above into three separate groups but by default have both Core and Tests selected I would have to create a separate default group for that. And that creates confusion because you can't really present that in a UI properly. Not sure if this helps or not... First off one can load more than one target. The #load: method can take a string or a collection of strings, so if the groups 'default', 'Tests' and 'Optional' exist one can specify #('default' 'Tests' 'Optional') as the argument to the load ... Secondly, metacello takes care of overlap and duplication internally while resolving the list to a set of packages/projects, so you don't have to create groups for all of the possible combinations of groups. In the above you can just add the selected group to the load list... Dale |
In reply to this post by Göran Krampe
Göran Krampe wrote:
> One interesting trick that Lunar uses (and probably all source distros) > is that when doing the "make install" (or whatever some tar ball wants > to do) phase of a module installation, Lunar first installs low level > filesystem "hooks" to capture ALL modifying file operations performed > during that phase. > > As Andreas noted, there is a supplyingAnswers: spec in Metacello that allows you to specify the answers to be supplied on a per package basis... With Metacello, instead of doing a direct #load, you can do a #fetch/#load. After the #fetch you will have a list of the package specs that are scheduled to be loaded, so it is (theoretically) possible for a tool to run through the supplying answers list and change the default answers in the configuration, then the modified specs can be #loaded.... > This way Lunar always knows EXACTLY what files a certain module actually > did install, and it can then uninstall it cleanly and keep track of > where files "came from". > Metacello does not keep a data base of installed packages. The image is the data base ... when you ask a configuration for it's current version, the current version is calculated based upon a best match of the packages installed in the current image and the versions in the configuration (#versionStatus gives you a measure of the fidelity of the currentVersion against the existing image). By keeping no state, it is possible to unload Metatacello and then at a later date reload Metacello and then do upgrades without having do any data base reconciliation... In a future version of Metacello I will add the ability to #unload a configuration (and keeping with the fetch/load idea there will be the ability to precompute the unload for review by a human or an algorithm)...I am interested in getting the load half of the equation resolved before tackling unload ... Dale |
Free forum by Nabble | Edit this page |