July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 21 Jul '09

21 Jul '09

Feature changed by: Lubos Lunak (llunak) Feature #305586, revision 25 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. #6: M. S. (funkym) (2009-01-17 13:05:51) libnotify does all that and ontop is based on a desktop independent freedesktop specification (http://galago-project.org/specs/notification/index.php) for notifications to adopt by any desktop environment. It is written in C which is much more suitable for daemons and provides bindings for D- BUS, Mono, Python and Vala. Interactive notifications are already used widely; take PackageKit as an example. The developer of growl is also interested to improve libnotify as they are closely related and friends with the maintainer. A cross desktop friendly notifications utility in Python is the right thing to make things worse. If you want the bling just create a different theme for libnotify... What libnotify needs though is a bit of coding love to implement stuff like network notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES! $2c #7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6) It's no longer the question whether to switch from one to the other. Mumbles is able to intercept libnotify messages so we can provide it "on top" and switch. Then it's a question of defaults and what we like this to become. #10: Andreas Jaeger (a_jaeger) (2009-07-09 10:21:44) Ubuntu is working on a notification framework well (https://wiki.ubuntu.com/NotifyOSD). Are those in a state that we can make a decision to go one way or the other? Initially we could add it as optional package and ask for feedback with Milestone 4 - and then decide what to do. #11: Will Stephenson (wstephenson) (2009-07-09 14:34:30) (reply to #10) The discussion about notification APIs is still very active on the XDG list. I recommend not adopting either the Ubuntu proposal or the galago derived fdo Notification spec until a standard has been agreed. 1) The Notification spec is not a standard. Its unilateral assumption of the org.freedesktop.Notification namespace is controversial. A standard spec is still under discussion. 2) The Ubuntu design makes strong and arbitrary restrictions on what can be shown in the notification. The intention of the current discussion is to design a notification API that can be a superset of the Ubuntu proposal and provides the features required by several projects outside Ubuntu. Since a productive discussion is still taking place, making a premature decision would undermine the XDG standards process and cause additional work when a final spec is agreed. - + #12: Lubos Lunak (llunak) (2009-07-21 15:05:15) + This request is confused on several fronts. At least one of our + desktops, KDE, has had such a framework, KNotify, since ages. Mumbles + itself declares itself to be "a plugin driven, modern notification + system for Gnome", so it doesn't look very desktop independent. And it + is enough to read the XDG list to see that libnotify is in fact not a + standard or anything close either. I assume that it will still take + some time to reach any usable consensus on an actual specification for + notifications, so there is probably not much to be done here for 11.2 + besides joining the XDG discussions (unless, of course, this proposal + in fact wanted to be named 'GNOME notification framework'). -- openSUSE Feature: https://features.opensuse.org/305586

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 21 Jul '09

21 Jul '09

Feature changed by: Michael Andres (mlandres) Feature #302159, revision 41 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. + #17: Michael Andres (mlandres) (2009-07-21 12:30:27) + libzypp-6.11.0 allows to set different download policies in + ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, + DownloadAsNeeded). -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 306904] Distributed Shared memory library
by fate_noreply＠suse.de 20 Jul '09

20 Jul '09

Feature added by: Peter Morreale (pmorreale) Feature #306904, revision 1 Title: Distributed Shared memory library Hackweek IV: Unconfirmed Priority Requester: Desirable Requested by: Peter Morreale (pmorreale) Description: The feature is a library to allow applications to reference and maintain shared memory segments with consistent data across a network fabric. This is similar to the old DEC Memory Channel functionality that allowed multiple machines to read and write to specific memory locations on those nodes. A couple of our customers have asked for similar functionality and as a result, I have been working on a initial implemention. For more specific information, please contact me directly. -- openSUSE Feature: https://features.opensuse.org/306904

1 3

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 20 Jul '09

20 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #120340, revision 94 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... + #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) + Guys, as Duncan wrote in c#16, we are already developing the "download + all, install all" mode (currently we only have "download one, install + one, ..."), and yes, users will be able to choose one of these. This + particular feature would be an improvement of the current mode: + "download one, install one while downloading others, ...". I hope this + clarifies the current status a bit. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 306914] Emesene
by fate_noreply＠suse.de 19 Jul '09

19 Jul '09

Feature added by: Adrian maravilla (fulapol) Feature #306914, revision 1 Title: Emesene Package Wishlist: Unconfirmed Priority Requester: Neutral Requested by: Adrian maravilla (fulapol) Description: I really like to see the emesene package in repositorys -- openSUSE Feature: https://features.opensuse.org/306914

1 1

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 18 Jul '09

18 Jul '09

Feature changed by: Vincent Untz (vuntz) Feature #305296, revision 105 Title: Easy Way to Disable Beagle Completely During Installation - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) you are luky then.. beagle on my pc make them very very slower, it should be disabled by default, if you need it, then you insta/activate it #34: Marc collin (collinm) (2009-07-04 15:03:05) Disable it by default, i use kde... and there is alreay a solution for it.... we could also disable mono... #35: Michael Löffler (michl19) (2009-07-07 11:29:54) Vincent, can you do this? As it is our highest rated feature it would be very good to have implemented rather soon then later. Thanks. #36: Vincent Untz (vuntz) (2009-07-07 12:09:24) Well, it depends on what is the decision here: * if it's something that should be done during installation, I have no idea how to implement that. * If it's just disabling beagle by default, I'll need to investigate, but it hopefully only is changing something in a .desktop file. So what's the process on taking a decision here? That being said, just disabling beagle by default might expose a usability issue: if it's disabled, it will not index files. So when the user searches for something for the first time, it will not work and users won't understand it, and will just give up on it. (It might be solvable with a nice message the first time the user does a search, though) #37: Michael Löffler (michl19) (2009-07-07 14:43:12) (reply to #36) Vincent, please see #1. What you describe is exactly what Federico suggested as well. So I'd say disable beagle by default and offer option to run at first search. #38: Karl Eichwalder (keichwa) (2009-07-07 15:08:23) (reply to #37) IIRC, the kde help center works this way and it is rather annoying. Most of the time, the desktop computer idles... I think on the Mac the desktop search (spotlight) is enabled by default. #39: Stephan Kulow (coolo) (2009-07-07 15:16:24) (reply to #38) you're wrong. Most of the time, the desktop computer saves power. #40: Karl Eichwalder (keichwa) (2009-07-07 15:36:52) (reply to #39) Yes, you are right. Once the work is done. On my desktop at work, beagled and beagled-helper do not cause any notable load. It's different on my test machine, though. #41: Dean Hilkewich (deanjo13) (2009-07-07 16:36:55) (reply to #38) When it comes to indexing services spotlight is far ahead of beagle in usability and performance. It is also easily disabled with a system setting if desired. Even on old G4's spotlight doesn't kill performance like beagle does. #42: Segundo Luis Martín Díaz Sotomayor (zchronos) (2009-07-07 17:47: 18) Beagle should be disabled by default. + #49: Vincent Untz (vuntz) (2009-07-18 18:42:21) + Fixed in GNOME:Factory, and submitted to openSUSE:Factory (#14802). -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 306908] Access control in Build Service
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature added by: Srinidhi B S (srinidhi) Feature #306908, revision 1 Title: Access control in Build Service Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Srinidhi B S (srinidhi) Description: Implement access control in Build Service so that a project maintainer or admin can disallow "read" access to a project / package according to the accessing "user's roles". Currently, "all users" have read access and any user with "maintainer" role inside a project / package can write to the project / package. Extend the existing "permission" set so as to allow more granular ACLs. Not sure if this would really make sense to a public instance of Build Service - like the OpenSUSE Build Service itself - but has real value in a local Build Service instance. Use Case: TeamA and TeamB are involved in the same project (or product, since Build Service has no distinction) in a local instance of Build Service. TeamB is working on a new package, say alpha, inside the same project whose sources have a proprietary nature or fall under some kind of Non-Disclosable agreement. TeamB wants to continue leveraging the power of Build Service for this package as well. As of today, there's no way TeamB can hide the sources of "alpha" from members of TeamA. But with the help of ACLs, TeamB's project maintainer can easily set permission flags on package "alpha" to be accessed only by the members of TeamB. -- openSUSE Feature: https://features.opensuse.org/306908

1 0

[openFate 305692] Better hardware support in SAX
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature added by: Andrey Karepin (EGDFree) Feature #305692, revision 1, last change by Title: Better hardware support in SAX openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Andrey Karepin (egdfree) Partner organization: openSUSE.org Description: For example: * horizontal scrolling on mouse Logitec G5 out of the box * add to SAX profile keyboard Logitec Wave, with the support of all the extra keys (multemidiynyh and Fn) * add to SAX profile for your monitor Acer P223W (P243W, etc.) and its auto-detect -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305692

1 11

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #302306, revision 65 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432), maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #302306, revision 63 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Jiri Srain (jsrain) + reject date: 2009-07-17 10:19:44 + reject reason: Let's do it early in the 11.2 development cycle to have + feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Mandatory Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432), maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: - * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) - BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. - as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. -- openSUSE Feature: https://features.opensuse.org/302306

1 0