Dňa Friday 24 August 2007 12:13:26 Duncan Mac-Vicar Prett ste napísal:

On Friday 24 August 2007 11:03:39 Stefan Schubert wrote:

...

Katarina Machalkova schrieb:

...

Provided that this method is really deprecated, I'm probably supposed to use something else instead, to achieve the same goal in UI ;-) Could you please point me to some other libzypp method I can possibly use, or advise me how to collect names of the packages that will be installed once user select a pattern?

This was a very quick hack and with a lot of unexpected behaviour. Now you only have to select the pattern and make a complete solver run. The solver will select the concerning packages which you will have to pick up then.

That is exactly the point we have been discussing from the beggining.

- ZYpp developers can't accept the fact that someone wants to look pattern "contents" instead of looking the result of selecting a pattern at transaction time.

- UI developers insist that patches and patterns have content. While the poor Patch and Pattern class have no knowledge about that, they just depends on things, and the solver knows what to grab. It is understandable, because the UIs were mostly "adapted". A new concept is needed here. I agree at least for patterns, being able to see packages one by one is really useful, I use it a lot, but I would call it "related packages", and not the content of the pattern itself.

I need an explanation for a user what a pattern is. I mean, user concept, not a technical description. Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Dňa Friday 24 August 2007 13:05:32 Stefan Schubert ste napísal:

Duncan Mac-Vicar Prett schrieb:

...

On Friday 24 August 2007 11:03:39 Stefan Schubert wrote:

...

Katarina Machalkova schrieb:

...

Provided that this method is really deprecated, I'm probably supposed to use something else instead, to achieve the same goal in UI ;-) Could you please point me to some other libzypp method I can possibly use, or advise me how to collect names of the packages that will be installed once user select a pattern?

This was a very quick hack and with a lot of unexpected behaviour. Now you only have to select the pattern and make a complete solver run. The solver will select the concerning packages which you will have to pick up then.

That is exactly the point we have been discussing from the beggining.

- ZYpp developers can't accept the fact that someone wants to look pattern "contents" instead of looking the result of selecting a pattern at transaction time.

Hm, the "normal" user is not interested in the content of a pattern. So the "general" UI should not provide this information in the main view.

In fact, I don't agree. I want to see what will this beast do. I don't care how you name it, but 'content' is pretty sound name for the thing I want to see. Technically, you are right, you want to see how the dependencies will influence your system. But that's hard to explain in non-technical terms. Anyway, the UIs will need to have a way to provide this information IMO. Stano

For that use vi :-) or xv ~schubi/Export/solvertree/kde.jpg

...

- UI developers insist that patches and patterns have content. While the poor Patch and Pattern class have no knowledge about that, they just depends on things, and the solver knows what to grab. It is understandable, because the UIs were mostly "adapted". A new concept is needed here. I agree at least for patterns, being able to see packages one by one is really useful, I use it a lot, but I would call it "related packages", and not the content of the pattern itself.

Yes, and that is what the user wants to see. "What will be installed/deleted if I select/deselect this"

...

The function is deprecated for anyone using the Pattern API. PatternContent is allowed to do nasty things because it assumes anyone using PatternContent is a nasty application ;-), we should probably move that "mini-solver" to the zypp/ui directory.

It does not exists anymore in 10.3 cause none use it, or the use has no effect anymore.

Greetings Stefan

-- *************************************************************************** **** Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de --------------------------------------------------------------------------- ---- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Schubert schrieb:

The function is deprecated for anyone using the Pattern API. PatternContent is

...

allowed to do nasty things because it assumes anyone using PatternContent is a nasty application ;-), we should probably move that "mini-solver" to the zypp/ui directory.

It does not exists anymore in 10.3 cause none use it, or the use has no effect anymore.

That is not true. It still does exists. So we have two cases how we look onto patterns in the QT-UI: Case 1:The user select a pattern ( do not select for installation/deletion): On the right side packages will be shown which has to ANYTHING with that pattern. This is an information what COULD belong e.g. to a webserver pattern only. For that case we are using the PatternContent mechanism. HuHA is that correct ? Case 2:The user install a pattern: The user wants to see which packages will be definetely installed. In that case we make a complete solverrun. The result is completely independent from Case 1. So, some packages of Case 1 can be installed or not and other packages which are not part of the selected patterns can be installed too ( due dependecies ). So, Katerina which kind of view do you need ? -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

So we have two cases how we look onto patterns in the QT-UI:

Case 1:The user select a pattern ( do not select for installation/deletion):

On the right side packages will be shown which has to ANYTHING with that pattern.

Right (PatternContents() and friends)

Case 2:The user install a pattern: The user wants to see which packages will be definetely installed. In that case we make a complete solverrun. The result is completely independent from Case 1.

No, it does not work that way. The list of packages user sees in the right panel is the same as in Case 1. Yes, we make complete solver run, and yes, dependent packages/patterns are marked for installation/update/deletion, but the list of 'related packages' in the right panel remains the same. The *only* difference is that their status changes. The user never sees the complete list of packages that will be installed once he/she selects a pattern in the right panel So the resulting list is obtained via PatternContent::install_packages() in both cases. The output of ncurses UI is identical - either you 'select' the pattern from the popup list, press 'OK' and see related pkgs in the main table (case 1), or you mark pattern for installation in the popup list (case 2), press 'OK' and see exactly the same list, only with updated status of the pkgs.

So, Katerina which kind of view do you need ?

Ideally, I would need both :) because as I described above, current behaviour is a bit buggy as we get the same list in both cases (1 and 2) where we should get two different ones. B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

On Friday 24 August 2007 11:03, Stefan Schubert wrote:

Katarina Machalkova schrieb:

...

Provided that this method is really deprecated, I'm probably supposed to use something else instead, to achieve the same goal in UI ;-) Could you please point me to some other libzypp method I can possibly use, or advise me how to collect names of the packages that will be installed once user select a pattern?

This was a very quick hack and with a lot of unexpected behaviour. Now you only have to select the pattern and make a complete solver run. The solver will select the concerning packages which you will have to pick up then.

But that's not the same. As a user, I want to know what packages I'll get before I select a pattern. If the new behaviour is like you described, the user will se no pattern content (no packages) before selecting the pattern and all packages that somehow got dragged into the install set (regardless whether by the pattern or otherwise) afterwards. This invalidates the whole idea of that "Patterns" filter view. The only thing that would make sense would to only have the simple pattern selector that only shows the pattern description and no content. This in turn does not fit at all into the package selector framework: There, you can switch between different filter views that all have one thing in common: They have a list of packages. In NCurses, there is no counterpart to the simple pattern selector. In Qt, I would feel forced to throw the patterns filter view out of the package selector (because without a package list it really is out of place there). This OTOH would be a big step backward for the users. Very much the same would be true for patch contents that (AFAICS) has the same problem: No list of packages any more. How are we going to go ahead with this? CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Friday 24 August 2007 06:50:40 am Lukas Ocilka wrote:

Stefan Hundhammer wrote:

...

On Friday 24 August 2007 11:03, Stefan Schubert wrote: ... As a user, I want to know what packages I'll get before I select a pattern. If the new behaviour is like you described, the user will se no pattern content (no packages) before selecting the pattern and all packages that somehow got dragged into the install set (regardless whether by the pattern or otherwise) afterwards.

This invalidates the whole idea of that "Patterns" filter view. The only thing that would make sense would to only have the simple pattern selector that ... Very much the same would be true for patch contents that (AFAICS) has the same problem: No list of packages any more.

That's true, as a user, I always check which packages a patch/pattern contains because I want to know the relation between the patch/pattern (name) and its content (what it affected, what else should I select...).

Such statements as "user doesn't want", "user wants", "user needs" should be supported by, at least, some mail written to the community at factory@opensuse or some Internet survey.

It seems we need to provide surveys *before* we change some important parts, or, at least, *after* we change them (however *before* sounds better).

Frankly, I've found, that all of us (including myself, of course) are "freaks" :) that don't now what the real life is :) ;) We know our distribution, we know our packages, we know our source code, but we really *don't know* what our users want...

Is There Anybody Out There?

Not many Lukas ;-) It should be organized some survey to clarify what 'normal' user looks for or expects from certain screen. For me Patterns is the way to see packages sorted by functionality. If I want web (any kind of) server, I look in pattern sever functions what will be included, what else is offered, but not included by default. Pattern is some kind of expert advice. For instance Console Tools is my, recently discovered, shortcut to check in few tools without loosing time looking around or typing names in a search. The package groups are helpfull for this kind of browsing too, but I don't know is it maintained after introduction of patterns. Search is not good for this as it depends on name/summary/description that may or may not contain search word. -- Regards, Rajko. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On 24/08/07, Stefan Hundhammer wrote:

As a user, I want to know what packages I'll get before I select a pattern. If the new behaviour is like you described, the user will se no pattern content (no packages) before selecting the pattern and all packages that somehow got dragged into the install set (regardless whether by the pattern or otherwise) afterwards.

I think this might because you are an advanced user who understands package management. Do you think $User who wants to install KDE really cares that he needs to install libqt kdelibs kdepimlibs libkde kde-konqueror kde-kget etc etc? I'm not so sure seeing pattern content prior to selection is necessary for non-technical users. The result of potential installation can be displayed post-solve as the API permits. I knocked up a quick functional pattern selector in YCP that operates in this manner: http://benjiweber.co.uk/patternselector/1-select-patterns.png http://benjiweber.co.uk/patternselector/2-display-results-of-solve.png http://benjiweber.co.uk/patternselector/3-apply-changes.png If you want to play grab http://benjiweber.co.uk/patternselector/patternselector.ycp

This invalidates the whole idea of that "Patterns" filter view. The only thing that would make sense would to only have the simple pattern selector that only shows the pattern description and no content. This in turn does not fit at all into the package selector framework: There, you can switch between different filter views that all have one thing in common: They have a list of packages.

By the simple pattern selector do you mean http://benjiweber.co.uk/patternselector/_existing_pattern_selection_widget.p... ? I have to admit I haven't seen it used on its own like this, do any modules use it?

In NCurses, there is no counterpart to the simple pattern selector.

This would not be an issue if it were entirely implemented in YCP. _ Benjamin Weber -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Saturday 25 August 2007 00:52, Benji Weber wrote:

I knocked up a quick functional pattern selector in YCP that operates in this manner:

http://benjiweber.co.uk/patternselector/1-select-patterns.png http://benjiweber.co.uk/patternselector/2-display-results-of-solve.png http://benjiweber.co.uk/patternselector/3-apply-changes.png

I know. I wrote that thingy. ;-) That's the novice user's approach to patterns. And for novice users, this makes perfect sense. But I have yet to come across the first non-novice user who doesn't klick on the "Details..." button to see all the gory innards. And for them there is the patterns filter view with packages listed. We didn't have that right from the start when we began supporting patterns, and it proved to be very annoying to have to switch back and forth between the pattern selector and the detailed package selector. CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org