[yast-devel] Starting repo management from the pkg manager
Hi all! Many users complain why there are two separate modules for managing repositories and packages. They want to add/refresh/enable/disable/... repositories from the package manager widget. Currently you have to close the package manager module, start the repository manager, do the action you want and start the package manager again. It takes a long time and you have click too many times. Adding the repository management functions to all package manager widgets requires a lot of work in each UI frontend. I created a small patch which can start the repository manager module directly from the package manager, almost all the changes are on the YCP level. Pros: + simple implementation, the patch has just few lines Cons: - the repository manager is not visually integrated to the package manager See the attached patch, install patched "packager" and "qt-pkg" yast modules. The patch adds a new menu entry in the package manager widget, click "Extra" -> "Repository manager..." or press Ctrl + M shortcut. (This feature can be made more visible if needed, e.g. add a button into the "Repository" filter or something like that...) What do you think about this solution? Is it a good thing for 11.0? -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
Hi Ladislav, there is a FATE entry for this: 302517 I have added you as interested there. Here is a quote of my entry regarding this topic: I makes sense if software management module becomes a module where everything around package management is integrated (like synaptic used e.g. by Ubuntu). In our case the advantages would be: * more efficiency as the user doesn't need to search through nine modules in the control centre as modules for less frequent actions are integrated into software management module * conformity with user expectations (software management includes everything I need to manage my software) * clearer structure of control centre because of less modules The disadvantages are: * users need to learn about the new ways of software management * new module might look overcrowded To be honest, integrating anything into the current software management UI would be a mess, as the current layout is already quite complex. Therefore I suggest a simplification of the software management module and an integration of all software management related functions: http://en.opensuse.org/Usability/Softwaremanagement#Simplifying_Software_Man... The basic concept is: * searching and browsing of packages is the core function of software management and therefore prominent * less frequently used functions are moved to the menu bar Search and browse tabs: * The somewhat difficult to understand status icons (install, taboo) are acompanied by some description to make them easier understandable (please not, that the icons used in the mockup are not the original ones because I was not able to find them) * Search settings includes options for "Search in" (name, summary, description, RPM provides, RPM requires), "Search Mode", case sensitve yes/no. I chose status, package name and summary as columns because they seem most important to me and this amount of columns doesn't force the user to scroll horizontically (which, I think, we all agree, is something that should be avoided if possible :-)) If you like to include other columns (available/installed version, size,...) please let me know. * Disk usage was dropped. I think that in times of the current storage prices, this overview is outdated * Dependency checks moved to the menu. I suppose that most users will use autocheck. For those who prefer a manual check, maybe we can create a shortcut The menu bar (please note that some entries will have check boxes (e.g. autocheck dependencies) I was just not able to create them with qt designer) * Software: includes all settings from current software management module. The package all in this lists option can be integrated into the "package" sub menu. Mge came once up with the idea to connect software management with bugzilla, so I put a "Report a Bug" item. * Online Update: "run online update" and "settings" will start the corresponding YaST modules * Novell Customer Center: "Register" starts corresponding YaST module, "Start NCC" opens NCC in a browser. Maybe this menu point is more interesting for SLES and if there is any need to hide the term registration from the community users, then we just give the baby a different name :-) * Repositories: opens the corresponding YaST module. I suggest to integrate the repositories according to FATE #303458 Simplifiying Software Management I think, I perfectly reversed your pros and cons: pro: * integration of repo management con: * quite some coding effort (at least for the UI) What do you think about that? Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Schmidkunz wrote:
there is a FATE entry for this: 302517 I have added you as interested there.
Thanks! [...]
I think, I perfectly reversed your pros and cons: pro: * integration of repo management
con: * quite some coding effort (at least for the UI)
What do you think about that?
I think that a full integration is the right way to go. I just want to create a step between the current state (no connection between the modules) and the future (the full integration). Full integration will take much time, it's definitely not for 11.0, this change is simple and is doable for 11.0. The question is whether my change is a good thing for 11.0 as a temporary solution for the problem. In my opinion yes, it definitely helps yast users. Ladislav -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ladislav Slezak wrote:
Thanks!
You're welcome! I would have added you before, but I didn't know, you are involved in this topic. It is sometimes hard for me to keep track, who is responsible for which topic in YaST :-)
The question is whether my change is a good thing for 11.0 as a temporary solution for the problem.
I think, that it is a good solution! As you already mentioned, putting the repo entry into the extra menu might make it difficult for the users to find it. A solution might be to include an entry "Repository Management" (or something similar) between "Extras" and "Help". When clicking on it, the menu drops down and an entry called "Start Repository Management" (or "open" or "launch" or what ever you find appropriate) appears, which starts repo management. The "Start Repository Management" could also be started by a short cut (like Ctrl+M as you already proposed). This might make it easier for the user to notice, that he can start repo management from the software management module. Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 14 March 2008 11:25, Martin Schmidkunz wrote:
Therefore I suggest a simplification of the software management module and an integration of all software management related functions: http://en.opensuse.org/Usability/Softwaremanagement#Simplifying_Software_Ma nagement
Uh - that's a completely new topic. It deserves its own thread IMHO.
CU
--
Stefan Hundhammer
On Friday 14 March 2008 11:25, Martin Schmidkunz wrote:
Therefore I suggest a simplification of the software management module and an integration of all software management related functions: http://en.opensuse.org/Usability/Softwaremanagement#Simplifying_Software_Ma nagement
The basic concept is: * searching and browsing of packages is the core function of software management and therefore prominent * less frequently used functions are moved to the menu bar Search and browse tabs:
That's inconsistent IMHO. There is a separate view for "Search", yet all the other views are hidden behind "Browse". The most important widget there is the "Filter" combo box which is just a less space consuming version of additional tabs for all the filter views we have.
* The somewhat difficult to understand status icons (install, taboo) are acompanied by some description to make them easier understandable
That text consumes a considerable amount of screen space. It will make the relevant parts of that table scroll out to the right. And now think about how much more screen space this will cost for more verbose languages like German or French. Learning icons is a one-time effort. And the textual descriptions for each of them have been here all the time; just look at the context menu you get when you right-click any of them.
* Search settings includes options for "Search in" (name, summary, description, RPM provides, RPM requires), "Search Mode", case sensitve yes/no.
Why is this hidden behind a button? This makes it a lot less accessible IMHO. And you have to remember your current settings. You might keep wondering why you don't get any results if you forgot that you changed something there.
* Disk usage was dropped.
That's BAD. A zillion users complained about it when this didn't work for a while during the libzypp migration. This is something many users want to have.
I think that in times of the current storage prices, this overview is outdated
This argument is true only for your new average electronics megastore PC. For users installing a file server for the basement or a surf machine built from old parts this is different. And IIRC S/390 users tend to allocate a lot less resources to any single virtual machine they install Linux on. And that's just a few examples.
* Dependency checks moved to the menu. I suppose that most users will use autocheck. For those who prefer a manual check, maybe we can create a shortcut
I am not so sure about the future of manual dependency check either. We might choose to do auto-checking only. From what I see and hear of the new SAT-solver this might make sense.
The menu bar (please note that some entries will have check boxes (e.g. autocheck dependencies) I was just not able to create them with qt designer) * Software: includes all settings from current software management module.
You can't have a menu entry "Software" in a package selector. It's ALL about software. This needs to be more specific. And stuffing everything in there that makes up the functionality of this package selector and putting other, mostly irrelevant stuff to the top level menu instead is disregarding what users want to do with this tool. Veto.
The package all in this lists option can be integrated into the "package" sub menu. Mge came once up with the idea to connect software management with bugzilla, so I put a "Report a Bug" item.
Why here, and not at all the other places where bugs might occur (all the configuration modules)? This is inconsistent. If you look at any KDE application, you will find "Report bug" in the "Help" menu. This is where this kind of thing belongs, and this is where users are used to look for it. BTW if MGE wants this, please inform him that he also has to come up with an infrastructure like the KDE project has to filter out duplicates etc.. You can't do this without this kind of first-level-filter-out-useless-stuff mechanism. And that has to be in place before we add any such menu entry.
* Online Update: "run online update" and "settings" will start the corresponding YaST modules
As far as users are concerned, "online update" is just another view on the same level as all the others. It's even technically implemented like that. (Hint: Press F2 in the package selector).
* Novell Customer Center: "Register" starts corresponding YaST module, "Start NCC" opens NCC in a browser.
While Novell marketing will love us for putting that stuff so prominently there as a top-level menu item, I am sure that 98% of all users will just hate it. For users it's just a nuissance. If you do it at all, you do it once in the life time of your system. You don't want to be bothered with irrelevant stuff like that all the time on that level. If we have to put this anywhere (which so far nobody even requested AFAIK), it has to go somewhere else - somewhere in a "Settings" menu or something similar.
Maybe this menu point is more interesting for SLES
It will annoy SLES users just as much as openSUSE users. I am pretty sure that customers who want to use the Novell customer center have a completely different workflow when it comes to software installation anyway. They are not going to let individual users mess with packages. They deploy software in different ways.
and if there is any need to hide the term registration from the community users, then we just give the baby a different name :-)
* Repositories: opens the corresponding YaST module. I suggest to integrate the repositories according to FATE #303458 Simplifiying Software Management
Repositories make sense here. Unlike the others, this makes sense on this
level.
What is missing from the menu is all the important stuff. I don't see anything
about packages, about patches, about help, about settings.
CU
--
Stefan Hundhammer
On Friday 14 March 2008 14:05, Stefan Hundhammer wrote:
There is a separate view for "Search", yet all the other views are hidden ^^^^ tab behind "Browse". The most important widget there is the "Filter" combo box
CU
--
Stefan Hundhammer
* Disk usage was dropped.
That's BAD. A zillion users complained about it when this didn't work for a while during the libzypp migration. This is something many users want to have.
I dare to disagree. I believe that users does not need to have a nice, cool-looking bar graph of current disk space status in front of his/her eyes all the time. It is a waste of screen space and there are quite some more useful information that could be displayed instead - e.g. pattern description. What user really needs is to be notified when disk space is running out / has already run out. And, if user wishes, (s)he can always go to the menu and view current waste^Wusage of diskspace in a pop-up upon request. In new ncurses pkg selector, there is no space for such graph to be visible by default anyway, so I made 'Show available disk-space' just an entry in 'Miscellaneous' menu. And, of course, a warning pops up each time the disk space is running out. B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
* Disk usage was dropped.
That's BAD. A zillion users complained about it when this didn't work for a while during the libzypp migration. This is something many users want to have.
I dare to disagree. I believe that users does not need to have a nice, cool-looking bar graph of current disk space status in front of his/her eyes all the time. It is a waste of screen space and there are quite some more useful information that could be displayed instead - e.g. pattern description I fully agree with you here. There are a lot of secondary information on
Katarina Machalkova wrote: the screen, that should be used to make primary information more attractive and more easy to read (color, big fonts, icons, etc.) disk usage is a pretty good example. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 14 March 2008 11:16, Ladislav Slezak wrote:
Many users complain why there are two separate modules for managing repositories and packages. They want to add/refresh/enable/disable/... repositories from the package manager widget.
The request is valid and makes a lot of sense. We wanted this for a long time.
Adding the repository management functions to all package manager widgets requires a lot of work in each UI frontend. I created a small patch which can start the repository manager module directly from the package manager, almost all the changes are on the YCP level.
Looks like I thought too complicated how to do this for a long time. I thought we'd have to reimplement all the functionality of the repo management on the C++ level. You found an unconventional approach that makes this a lot simpler. There will also not be any problems with outdated package selector internal data etc. because it simply gets restarted and thus freshly initialized. Nice work!
(This feature can be made more visible if needed, e.g. add a button into the "Repository" filter or something like that...)
What do you think about this solution? Is it a good thing for 11.0?
I think it's great. I vote for immediately checking this in.
CU
--
Stefan Hundhammer
Stefan Hundhammer wrote:
(This feature can be made more visible if needed, e.g. add a button into the "Repository" filter or something like that...)
What do you think about this solution? Is it a good thing for 11.0?
I think it's great. I vote for immediately checking this in.
That's what I wanted to hear :-) I'll add a new item to the main menu to make it more visible (as Martin suggested). Thanks! -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Hundhammer wrote:
What do you think about this solution? Is it a good thing for 11.0?
I think it's great. I vote for immediately checking this in.
DONE. We need to adapt also yast2-ncurses-pkg and yast2-gtk to support this feature. Bubli? Ricardo? Michael? The change should be really small, just add a widget which closes the packager widget with `repo_mgr symbol as the result. I can help you if you need. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, Sex, 2008-03-14 às 15:27 +0100, Ladislav Slezak escreveu:
We need to adapt also yast2-ncurses-pkg and yast2-gtk to support this feature.
Bubli? Ricardo? Michael? The change should be really small, just add a widget which closes the packager widget with `repo_mgr symbol as the result.
Added that option to yast-gtk. It might be useful in the future to consider making libzypp concurrent, but this was a positive change. We had already played with this in the past actually; I guess because we never got to modify the repositories module, it didn't work that well. Anyway, will be looking to play with this in the next Alpha. Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
(I'm starting new thread, even though this topic relates to pkg management module integration as well, it's not exactly the same) ... and while we're at it, what about intergrating "Online update", "Automatic online update" and "Online update configuration" into one module as well? Frankly, even /me as a yast developer can't tell out of my head, without launching the modules, what they're good for and what exactly they do :) So how can we expect our users will know? And no, please don't say it's useless to do something with these modules, because majority of the users use updater applets. According to yast survey, it's just opposite - 55% use yast online_update, while [kde/gnome]-updater holds only 20% B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
Dňa Friday 14 March 2008 06:35:09 Katarina Machalkova ste napísal:
(I'm starting new thread, even though this topic relates to pkg management module integration as well, it's not exactly the same)
... and while we're at it, what about intergrating "Online update", "Automatic online update" and "Online update configuration" into one module as well?
Good point. Any idea how to do it? Stano
Frankly, even /me as a yast developer can't tell out of my head, without launching the modules, what they're good for and what exactly they do :) So how can we expect our users will know?
And no, please don't say it's useless to do something with these modules, because majority of the users use updater applets. According to yast survey, it's just opposite - 55% use yast online_update, while [kde/gnome]-updater holds only 20%
B.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stanislav Visnovsky napsal(a):
Dňa Friday 14 March 2008 06:35:09 Katarina Machalkova ste napísal:
(I'm starting new thread, even though this topic relates to pkg management module integration as well, it's not exactly the same)
... and while we're at it, what about intergrating "Online update", "Automatic online update" and "Online update configuration" into one module as well?
Good point. Any idea how to do it?
At least "Automatic online update" and "Online update configuration" could be merged quite easily, for instance, in one module using tabs. "Online update" is a tool we run to get patches downloaded and installed the easies possible way. Merging it with those other two would produce rather more problems: * "Online update" should be as easy as possible, start a package manager, download patches, present them to user, install them... * If we merge it with the rest, starting the one-big-online-xyz would either disturb by refreshing sources and patches or it would have to start the online update on request which is one click more. I'd be for merging those two but "Online update" should stay alone (maximally there could be an option to run "Online update configuration" and/or "Automatic online update" from there). L.
I'd be for merging those two but "Online update" should stay alone (maximally there could be an option to run "Online update configuration" and/or "Automatic online update" from there).
What about re-using lslezak's trick for running repository manager from package manager and add 'Configure automatic online update' and 'Online update configuration' as menu options to patch manager (online_update)? (while keeping them as standalone module with two tabs, of course) Btw, I'd be strongly for renaming the latter to 'Register | configure update repository' because 'Online update configuration' is so generic term that it doesn't really tell one what to expect of this module ... Btw2, isn't now (as feature #302990 is being implemented - adding update repositories from repository manager) 'Online update configuration' aka 'Register | configure update repository' a little bit redundant? B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
On Tuesday 18 March 2008, Katarina Machalkova wrote:
I'd be for merging those two but "Online update" should stay alone (maximally there could be an option to run "Online update configuration" and/or "Automatic online update" from there).
What about re-using lslezak's trick for running repository manager from package manager and add 'Configure automatic online update' and 'Online update configuration' as menu options to patch manager (online_update)? (while keeping them as standalone module with two tabs, of course)
I like the idea of combining these modules. At least I've got a fate request related to this fate#303359 . For this I will have to change the registration anyway - so this is a good chance to merge these.
Btw, I'd be strongly for renaming the latter to 'Register | configure update repository' because 'Online update configuration' is so generic term that it doesn't really tell one what to expect of this module ...
I agree that the current name is quiet generic. But we once decided to use titles as captions and to get rid of actions and descriptions in captions. "Manage Software" : action "Software Management" : title And "Register | configure update repository" is an action as well. So lets find a good alternative.
Btw2, isn't now (as feature #302990 is being implemented - adding update repositories from repository manager) 'Online update configuration' aka 'Register | configure update repository' a little bit redundant?
Yes it is - a little :)
But otherwise you would have to go for "Software Repositories" to
configure something for the online update.
I think the big main tasks should have their entry in the control
center. But if there are two sounding very much like the same task,
they can most likely be merged.
And if we implement fate#302990 and fate#303359 the redundance will
decrease further. Then repository handling is handeled in "Software
repositories" and any configuration stuff reated to online updates is
done in "Online Update Configuration" (or in the renamed module, if we
find a fitting title for it). If the latter finds that there is no
update source yet it will of course still be able to fetch one, but
this will be an exceptional case then.
Ciao,
Daniel
--
J. Daniel Schmidt
J. Daniel Schmidt napsal(a):
On Tuesday 18 March 2008, Katarina Machalkova wrote: ... And if we implement fate#302990 and fate#303359 the redundance will decrease further. Then repository handling is handeled in "Software repositories" and any configuration stuff reated to online updates is done in "Online Update Configuration" (or in the renamed module, if we find a fitting title for it). If the latter finds that there is no update source yet it will of course still be able to fetch one, but this will be an exceptional case then.
You don't have to call Registration to get the update source :) Community Repositories have one YOU repository as well. And they (CR) can be called from YaST Repositories. L.
On Tuesday 18 March 2008, Lukas Ocilka wrote:
You don't have to call Registration to get the update source :) Community Repositories have one YOU repository as well. And they (CR) can be called from YaST Repositories.
I know - and I even discussed with coolo if/when we can get rid of
fetching an update source from ncc for the box.
This decision will as well influence fate#303359
Ciao,
Daniel
--
J. Daniel Schmidt
Dňa Tuesday 18 March 2008 06:43:08 Lukas Ocilka ste napísal:
J. Daniel Schmidt napsal(a):
On Tuesday 18 March 2008, Katarina Machalkova wrote:
... And if we implement fate#302990 and fate#303359 the redundance will decrease further. Then repository handling is handeled in "Software repositories" and any configuration stuff reated to online updates is done in "Online Update Configuration" (or in the renamed module, if we find a fitting title for it). If the latter finds that there is no update source yet it will of course still be able to fetch one, but this will be an exceptional case then.
You don't have to call Registration to get the update source :) Community Repositories have one YOU repository as well. And they (CR) can be called from YaST Repositories.
This works only for openSUSE. It would break even for openSUSE add-on products, if they would like to use registration capabilities of YaST/suseRegister. Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (9)
-
Duncan Mac-Vicar Prett -
J. Daniel Schmidt -
Katarina Machalkova -
Ladislav Slezak -
Lukas Ocilka -
Martin Schmidkunz -
Ricardo Cruz -
Stanislav Visnovsky -
Stefan Hundhammer