Hi Jon, sorry, in advance, for the nitpicking. :) I just think that apps which every user will get in contact with have to be as good as possible. On 4/14/07, DarkWyrm <darkwyrm@xxxxxxxxxxxxx> wrote:
I'm not normally one to be completely inflexible, but no. The original design is good and by staying close to it, development will be signficantly faster because there will be no debates over new designs to slow down the process. Minor tweaks here and there are OK, though, especially if they are usable or speed up development. Just like R5 is the target for Haiku R1, this should be also. If the original design were bad, I'd say go for it, but if it ain't broke, don't fix it. :-)
Don't we have enough time for debates? The official coding period starts May 28th and the students get nearly three months for coding. The installer isn't a *huge* application and Ryan already did some research on the .pkg format. I think we could spend one or two weeks on discussing a better design. If everyone disagrees, I'll concentrate on the most important issues.
> I think the tabs view should start at the same height as the list > view > (instead of its label) to make it more obvious that both views are > connected. The list view's label could be replaced with a BBox to > make > this even more obvious. No. BBoxes are used for grouping together controls which have belong in the same category (try the Mail preferences window), not as labels -- that's what BStringViews are for.
In this case we have two fields that belong together (install type, description/info) and the description already has a BBox around it (which wouldn't be necessary, anymore). Primarily, this was about making it more obvious that the tabs belong to the list view by moving them down a little bit. What about that?
> There could be capitalization issues, but I don't think we have > agreed > on any rules, yet. IIRC we officially changed from Apple-style capitalization rules to GNOME style. I just haven't updated the HIG.
Ah, right, I remember (on the commits ML). Then, the labels were correctly capitalized: http://developer.gnome.org/projects/gup/hig/2.0/design-text-labels.html#layout-capitalization But it should be "Installation type", then, if I've understood correctly.
Yes, we do. There are quite a few people that don't care what happens, but I personally like to know what's being installed on my system * before* I tell it to start. This is more of a feature for power users, but it doesn't get in the way for others, so it IMO should stay.
Experts can still use the package builder (or we could have a simple package inspector if there won't be a builder). IMHO, it does get in your way because by providing this feature you'll make a lot more people care (out of curiosity, just because it's there) and waste time on something that isn't important (works well without it on other platforms), makes the installer appear more complicated for non-technical people (or will we change the design for R2/R3?), and can't be changed, anyway. I think this feature was added for one single reason: you couldn't uninstall packages, so you had to know where the files go. As we had discussed via the GSoC web app, we want to have a simple uninstallation function (you couldn't have known this), so I don't see a reason for making that information so prominent. A separate inspector is more than good enough, IMHO.
> As far as I remember, many apps only have one single profile and > there > are rarely more than three profiles. IMHO, a list view is only > appropriate if: > * you expect to have many entries > * switching between entries must be very efficient > * you must have an overview of all elements > I think that of those three only the last one might apply, but a > pop-up field could be better suited for this task and result in a > more > compact UI. Very reasonable idea, but in this case, I don't think it's really hurting anything. In fact, if you asked me it's helping *because* it isn't as compact.
The pop-up field could be replaced with a BStringView when there is only one option, so you could easily recognize when multiple options are available (if that's your concern). Well, because of the installer's simplicity it indeed doesn't really hurt, so I won't insist on it. I just think it's overkill in most cases.
> Is there any need for splitting the installation volume and the > installation folder ("Install on ... in ...")? Why not have one pop- > up > with the full path? The pop-up could automatically offer pre-defined > paths for every volume and a "Custom..." item for choosing your own > path (when paths can't be chosen "Custom..." would be grayed-out). I believe that was the reason why -- if only the target volume could be selected, the folder selection popup was not displayed. Combining the two menus is a good idea only with two stipulations: 1) Common paths should be displayed for the boot volume. 2) Packages which only allow selection of the target volume display only volume names and icons.
I agree, but *maybe* (1) should also offer other BFS volumes since it could be a common use-case among experts to have multiple partitions. What do you think? Bye, Waldemar Kornewald