PATTERNS: ======== Since I constantly have some problems (artificial in fact) with patterns, I would like to suggest a bit of new (?) design. To avoid confusion with current design with patterns I will use another term -- template. STORY: ===== It is quite natural that user would like to have app A, B, C installed (for example, Firefox, OpenOffice and Skype). It could be guessed, it could be tested on real users, it does not matter -- but apps A B and C usually (!) come together. Of course user could each time click on A B and C to install them, but Yast could have something like templates. Template it is just a set (list of packages) -- when user says "refresh template T", A B C are not refreshed (!) but they are marked to be refreshed. If user says "install T", A B C are again _marked_ to be installed. Nothing more, no special logic. But of course somebody who makes that list cannot predict all users behaviour. Some group of users like A and B, but not C. Nevertheless template still can be used. For example: such user would choose "install T" and then click on C "do not install". REQUIREMENTS: ============ Consider such template: A, libA, B, C. 1) User chooses to install T except libA. Result? Conflict. Not because user installs partial T but because A requires libA. 2) User chooses to install T except B. No problem. 3) (next version of templates :-)). User chooses to install T except A. No problem, however it would be great if yast could notice libA was there just because of A, since libA is not required and was in template-install mode it could be set to "not install" (however user could still set it explicitly as to install) POSSIBLE HANDLING: ================= Yast could accept partial templates or warn about them. It could be an option. However I would opt for simply accepting users choices (see above cases). Why? Because there is no reason for warning. I don't like B -- why I should be warned? ADVANTAGES OVER CURRENT DESIGN (i.e. patterns): ============================================== * no artificial conflicts within template * no need to report such conflict to maintainers -- solved by design * developers and users time -- savings * natural way to express user needs DISADVANTAGES: ============= I've heard one so far. (not verbatim quote) Imagine a user who select T1 T2, T3 (templates) and so on, and then she/he focuses on individual packages and select "not install" on every package that rhymes with "foo". Such user should be warned about "broken" (i.e. partial) template. (end of not verbatim quote) In my opinion such opposition is not serious -- I don't think yast should be considered as treatmeant for people with zero (or low) responsibility, especially that yast design affects all users. Thanks you for your time, have a nice day, bye -- Maciej Pilichowski -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org