[zypp-devel] Deprecated Pattern::install_packages() ?
Hola zypp hackers! While building libzypp I've noticed that install_packages() method of Pattern class has become deprecated. So it is stated in related header file: /** \deprecated AFAIK unused old Selection interface method. */ std::set<std::string> install_packages( const Locale & lang = Locale("") ) const ZYPP_DEPRECATED; This is not exactly true, the method is called in zypp::ui::PatternContents, which in turn is used in all UIs to obtain names of the packages to be installed shown by UI to the user, once he/she selects particular pattern for installation. (i.e. go to package selector, select 'Pattern' filter, choose some pattern e.g. YaST development and the packages you'll see in the right panel are obtained with the help of zypp::ui::PatternContents::install_packages() method) 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? Thanks in advance B. P.S.: Cc-ing also HuHa and Michael, since all UIs are currently using this deprecated method -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
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. 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
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. - Trying to get a pattern content is like when you buy an electronic product that requires batteries (not included), and that it also gets enhanced by some accessory (not required) and pretend to find the batteries and the accessory in the box. PatternContent goes to the suppermarket really fast and takes all batteries that match AA and all headphones with jack type X, and put them into the box, or something like that. PatternContent is a hack to get that behavior. The code is in Pattern but as Katarina points out, it does not belong there. The method just iterates along requires, recommends and suggests and return the capability names if they are packages, not a very safe method, or call it better "a solver implementation in 4 lines of code". 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. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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
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
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. 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
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
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"
Cool :) That's what I was asking about in the beginning: If install_packages() method is deprecated, how to collect all these 'related packages' from the zypp pool in order to present them to the user? Which method to use? I would really appreciate some example of the code, or a link to related developer documentation And btw, to see packages one by one is imho useful also e.g. for languages, as I was already pointing out in bug #265826
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.
If you grep yast2-qt (ncurses, gtk) code for PatternContent and install_packages(), you will certainly find some usage of these functions, so it is wrong to assume no one uses it. Therefore, we either need to keep the old concept (and move it somewhere else, if appropriate), or come up with a new alternative all UIs would be able to use. B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
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
Dňa Friday 24 August 2007 14:27:56 Stefan Schubert ste napísal:
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 ).
There is Case 3: pattern is autoselected, user wants to check what does it mean. Stano -- 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 03:16:05 pm Katarina Machalkova wrote:
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
Then you are confirming it, you are looking related packages. Not content. Then we can define it: Every package named the same as the name of any dependency the pattern has. So, a pattern recommends/requires apache > 6.0 you have apache 5.0 available. Right now the UI will show apache 5.0 in the pattern contents list, even if it will not be selected by selecting the pattern. Under that definition, we could create RelatedNames or something like that, which give a set of names which appear in any depencies, and also a way to find Resolvables in the pool using those name list. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
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 <sh@suse.de> 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
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? Lukas
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 Saturday 25 August 2007 03:19, Rajko M. wrote:
The package groups are helpfull for this kind of browsing too, but I don't know is it maintained after introduction of patterns.
It is being maintained. But it's a slightly different grouping. CU -- Stefan Hundhammer <sh@suse.de> 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 24/08/07, Stefan Hundhammer <sh@suse.de> 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
Dňa Saturday 25 August 2007 00:52:16 Benji Weber ste napísal:
On 24/08/07, Stefan Hundhammer <sh@suse.de> 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 see your point, you mean that the current disagreement is due to the UI concept we use for softwaremgmt. This might work for a wizard, but becomes quite tedious for experimenting (Next/Back). Stano -- 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 <sh@suse.de> 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 Saturday 25 August 2007 00:52, Benji Weber wrote:
By the simple pattern selector do you mean http://benjiweber.co.uk/patternselector/_existing_pattern_selection_widget. png ? I have to admit I haven't seen it used on its own like this, do any modules use it?
Currently, it's only used during installation. We'd have to add yet another icon to the (already overcrowded) "Software" tab in the YaST2 control center. Alternatively, we'd have to do a two-step approach (like during installation) and show first the pattern selector and only upon clicking "Details..." the detailed package selector. I think most non-novice users would hate us for that. ;-)
In NCurses, there is no counterpart to the simple pattern selector.
This would not be an issue if it were entirely implemented in YCP.
Right. We'd again have to come down to the least common denominator of Qt and NCurses, throwing away all that eye candy (part of which is actually useful). That's what we definitely no longer wanted when we wrote the previous package manager with SuSE 8.1 a long time ago. Users had complained a lot (and with very good reasons) about the pre-8.1 package selection. It was slow, ugly and had very few features. I don't think we want to revert to that. CU -- Stefan Hundhammer <sh@suse.de> 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
participants (9)
-
Benji Weber -
Duncan Mac-Vicar P. -
Duncan Mac-Vicar Prett
-
Katarina Machalkova -
Lukas Ocilka -
Rajko M. -
Stanislav Visnovsky -
Stefan Hundhammer -
Stefan Schubert