[opensuse-project] application navigation/search tab for software management on yast
Something I did not include in the previous mail, partly because I forgot /partly because It can be implemented independently of the usability improved minimalistic yast is a extra tab for the yast software manager. This tab would focus on desktop applications exclusively. For example when I want to install one simple application for example openoffice, dozens of package appear, regular users are puzzled by it and don't get anywhere, and advanced users have to look out for the one right package to install or rigorous one-by-one selection. Packages are usually not suitable for non-technicall people. Also people looks software by what it does, not its category or name. So having an extra tab that is presented by defaut to non-tech users would make their lives easier. Por example a user wants to convert flv video to mp4 or avi, how to find quickly and throughtly?. With that meaning a broad selection and a correct selection in short time. There are two ways in my mind, one having a graphical catalog where the user click into sections like in a web-page to find what he wants, and the other having tag based contextual/semantic search. This last approach requires to tag accordingly the packages or having a separate "tags" database. Whatever the approach it should help the regular user find fast what he wants, be it multimedia/productivity/games/whatever. I'd like to hear your opinions. Thanks. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I'd like to hear your opinions.
There is a web project for doing this http://software.opensuse-community.org/ This couild be integrated with yast in future. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Benji Weber wrote:
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I'd like to hear your opinions.
There is a web project for doing this http://software.opensuse-community.org/
This couild be integrated with yast in future.
-- Benjamin Weber
I tested that page and the results are.. well.. not nice. For a "video converter" query it returns in the top 10 ========================================= mkgmap OpenStreetMap to GARMIN converter man2html A Unix manpage-to-HTML converter highlight A universal source code to formatted text converter. uvcvideo USB Video Class (UVC) webcam driver enca Charset and Encoding Analyzer/Converter Library mimetex LaTeX math expressions to anti-aliased GIF images converter latex2html LaTeX2HTML Converter mednafen Multiple video game console emulator wv Word 8 Converter for Unix farsight2 Framework for Audio/Video Conferencing Protocols ====================================== For "word processor" gives the lest worst: =============================== htmldoc HTML Processor that Generates HTML, PostScript, and PDF Files abiword A Multiplatform Word Processor wv Word 8 Converter for Unix pd Real-time patchable audio and multimedia processor libwps Library for reading and converting Microsoft Works word processor documents swfmill Swfmill is an xml2swf and swf2xml processor with import functionalities antiword A Free MS Word Reader for Linux and RISC OS textmaker Efficient, powerful word processor from Softmaker Software GmbH wf Simple Word Frequency Counter wv2 library to import Microsoft Word documents For "audio player" ================= banshee A Music Player perl-CDDB_get Read the CDDB entry for an audio CD in your drive perl-MP3 MP3::Info - Manipulate / fetch info from MP3 audio files calf Calf is a set of audio effect plugins celt The CELT ultra-low delay audio codec hda A program to send a HD-audio command libmpcdec Musepack Audio Decoder gramofile Digitize Audio Records rosegarden4 MIDI/Audio Sequencer and Notation Editor timidity Software Synthesizer and MIDI Player ================================= No Amarok! ;-) I think it is obvious, this does not work, and also does not have a better way to urderstand libraries apart from applications, that means desktop applications, which is the verry purpose of talking about applications. As final corolary this are the top 10 with the "games" keyword. ============================================ gnome-games Games for the GNOME 2.x Desktop kdegames3 Games for KDE kdegames4 Library for KDE Games childsplay A suite of educational games for young children physfs PhysicsFS file abstraction layer for games hatari An Atari ST Emulator Suitable for Playing Games raine Neo Geo CD and arcade game emulator focused on Taito and Jaleco games loki_setup Installer Program Mainly for Games clanlib A Portable Interface for Writing Games guichan A portable C++ GUI library designed for games using SDL and/or OpenGL. Of which 3 are more or less aceptable, the rest is nonsense when compared to the query. Someone looking for games under linux and opensuse, would just say that there are no games. There are relatevely few games on linuxland, but this land us from few to none on regular people perspective. Of course I know we can find on packman 3d shooters, arcade, etc. The question is why although packman is in the database it is not "searched". Which means, that packman contains games, the site "knows" but does not "find". of course looking by specific name and certain keywords I can find anything. But the way the site is now, it does not work as it should. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I tested that page and the results are.. well.. not nice.
Well it's a work in progress. You can also register and start tagging things up & rating things. When there's more user generated content the search can be adjusted to favour that. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Apr 1, 2009 at 3:15 AM, Benji Weber <benji@opensuse.org> wrote:
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I tested that page and the results are.. well.. not nice.
Well it's a work in progress. You can also register and start tagging things up & rating things. When there's more user generated content the search can be adjusted to favour that.
In my opinion depending on users is not going to work. Most users are lazy... Either packagers tag their packages, (which I don't think will happen) or we implemente via software something that read descriptions of packages and generates it own semantic dicctionary. How well the latter is going to work is subject to discussion. But it is easier to make software to work than make people to work. There is a lot of people and a lot of apps. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
On Wed, Apr 1, 2009 at 3:15 AM, Benji Weber <benji@opensuse.org> wrote:
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I tested that page and the results are.. well.. not nice.
Well it's a work in progress. You can also register and start tagging things up & rating things. When there's more user generated content the search can be adjusted to favour that.
In my opinion depending on users is not going to work. Most users are lazy...
Either packagers tag their packages, (which I don't think will happen) or we implemente via software something that read descriptions of packages and generates it own semantic dicctionary.
Well this is kind of what we have already. Indexer looks at package descriptions and .desktop files and tries to infer data where possible. Unfortunately there are no real rules for most of the metadata, so for every rule there are hundreds of exceptions. I think the only way for it to work is for people to teach the system. You can already select which source & binary packages make up an application, and define new applications. Then in future runs the indexer will respect your selections when discovering package updates.
How well the latter is going to work is subject to discussion. But it is easier to make software to work than make people to work. There is a lot of people and a lot of apps.
I'm not sure I agree here. Once it's easy enough people do contribute comments & ratings & tags on many websites nowadays. The key thing is making it easy enough to contribute, and we're not there yet. Not least because we can't even share login credentials with novell infrastracture. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Benji Weber wrote:
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
On Wed, Apr 1, 2009 at 3:15 AM, Benji Weber <benji@opensuse.org> wrote:
2009/4/1 Ricardo Cornet <rcornet@gmail.com>:
I tested that page and the results are.. well.. not nice.
Well it's a work in progress. You can also register and start tagging things up & rating things. When there's more user generated content the search can be adjusted to favour that.
The basic problem I found with that is that it count on a high number or technically proficient users. People who will find what they want without using the system at all. And regular people who need the system would either get frustrated because they don't understand what is wrong and give up or make sloppy decisions in tagging or no tagging at all.
In my opinion depending on users is not going to work. Most users are lazy...
Either packagers tag their packages, (which I don't think will happen) or we implemente via software something that read descriptions of packages and generates it own semantic dicctionary.
Well this is kind of what we have already. Indexer looks at package descriptions and .desktop files and tries to infer data where possible.
Well, the inference mechanism needs to be reworked.
Unfortunately there are no real rules for most of the metadata, so for every rule there are hundreds of exceptions. I think the only way for it to work is for people to teach the system.
As I already said, that requires a lot of technical people who would rather do something else. For example, there are a lot of false positives, marking them as "not what I want", would take too much effort.
You can already select which source & binary packages make up an application, and define new applications. Then in future runs the indexer will respect your selections when discovering package updates.
The most elementary keyword have few good matches, Googling the internet is still faster and less error prone. The system as it is, would take too much time and effort to be usable for regular people, who in the end is the only real people who would really need it.
How well the latter is going to work is subject to discussion. But it is easier to make software to work than make people to work. There is a lot of people and a lot of apps.
I'm not sure I agree here. Once it's easy enough people do contribute comments & ratings & tags on many websites nowadays. The key thing is making it easy enough to contribute, and we're not there yet. Not least because we can't even share login credentials with novell infrastracture.
-- Benjamin Weber
Making it easy to help is great. But even if it is easy to contribute, system that depends on learning from the users is to slow in growing up to be effective. Lets say my mom wants an app that helps her to organize her teaching classes, istead of finding and app or getting a "not apps of that kind" response, she will get a long list of false positives. She would think "this thing does not work" and go somewhere frustrated by the percieved stupidity of the system. Telling her to "teach" the system is nonsense, and most people would think the same. Ricardo Cornet. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Onsdag den 1. april 2009 05:57:20 skrev Ricardo Cornet:
Something I did not include in the previous mail, partly because I forgot /partly because It can be implemented independently of the usability improved minimalistic yast is a extra tab for the yast software manager.
This tab would focus on desktop applications exclusively. For example when I want to install one simple application for example openoffice, dozens of package appear, regular users are puzzled by it and don't get anywhere, and advanced users have to look out for the one right package to install or rigorous one-by-one selection.
I'd like to hear your opinions.
I think history is full of examples of trying to make things easier and more minimalistic, and things ending up more confusing complex and unreliable and/or not doing what people need. Instead of doing it in a tab, maybe it could be done using a filter. Similarly to how Mandriva does it. So when you start up YaST software manager by default it will only search for gui apps. I guess this could be fairly easily integrated into the existing filter structure. Hope this image shows the Mandriva approach clearly - look at the top left combobox http://www.dedoimedo.com/images/computers/2009/mandriva-2009-software- management.jpg Btw. as I understand it, with the software managers unlike other YaST-modules you don't get both Qt and GTK "for free". So do you plan to do this for Qt _and_ GTK, or only or the other? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing. If you make something with a predefined list like in the screenshot of Mandriva (like our beloved "Groups" in Yast), it makes it easier to search in every language. The model approach is also interesting: one model to install everything default of OpenOffice (with the translation of your locale). 009/4/1 Martin Schlander <martin.schlander@gmail.com>
Onsdag den 1. april 2009 05:57:20 skrev Ricardo Cornet:
Something I did not include in the previous mail, partly because I forgot /partly because It can be implemented independently of the usability improved minimalistic yast is a extra tab for the yast software manager.
This tab would focus on desktop applications exclusively. For example when I want to install one simple application for example openoffice, dozens of package appear, regular users are puzzled by it and don't get anywhere, and advanced users have to look out for the one right package to install or rigorous one-by-one selection.
I'd like to hear your opinions.
I think history is full of examples of trying to make things easier and more minimalistic, and things ending up more confusing complex and unreliable and/or not doing what people need.
Instead of doing it in a tab, maybe it could be done using a filter. Similarly to how Mandriva does it. So when you start up YaST software manager by default it will only search for gui apps. I guess this could be fairly easily integrated into the existing filter structure.
Hope this image shows the Mandriva approach clearly - look at the top left combobox http://www.dedoimedo.com/images/computers/2009/mandriva-2009-software- management.jpg
Btw. as I understand it, with the software managers unlike other YaST-modules you don't get both Qt and GTK "for free". So do you plan to do this for Qt _and_ GTK, or only or the other? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Jean Cayron <jean.cayron@gmail.com>:
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing.
If you make something with a predefined list like in the screenshot of Mandriva (like our beloved "Groups" in Yast), it makes it easier to search in every language. The model approach is also interesting: one model to install everything default of OpenOffice (with the translation of your locale).
It has been designed with localisation in mind, but It's still missing a user interface for creating translations & choosing the locale, due to lack of time so far. Also the package repositories that are the original source of the data do not contain translations so we'd still rely on users or upstream to actually supply them. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Benji Weber <benji@opensuse.org>:
2009/4/1 Jean Cayron <jean.cayron@gmail.com>:
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing.
If you make something with a predefined list like in the screenshot of Mandriva (like our beloved "Groups" in Yast), it makes it easier to search in every language. The model approach is also interesting: one model to install everything default of OpenOffice (with the translation of your locale).
It has been designed with localisation in mind, but It's still missing a user interface for creating translations & choosing the locale, due to lack of time so far. Also the package repositories that are the original source of the data do not contain translations so we'd still rely on users or upstream to actually supply them.
For me, in software.opensuse-community.org, for a reasonible effort from translators, the best choice would be to translate predefined tags. Jean
-- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Onsdag den 1. april 2009 14:32:36 skrev Jean Cayron:
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing.
I think translations are included in the distro for package summaries and descriptions now. Though I'm not 100% sure ;-) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/1 Martin Schlander <martin.schlander@gmail.com>:
Onsdag den 1. april 2009 14:32:36 skrev Jean Cayron:
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing.
I think translations are included in the distro for package summaries and descriptions now. Though I'm not 100% sure ;-)
Yes, but is optional and not recommended due to a huge effort and only few languages do it Regards, Luiz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Jean Cayron wrote:
Also, if you make something like software.opensuse-community.org, it makes a problem for other languages than EN. It works only with keywords in English. If I type "Office" I have nice results, if I type "Bureautique" I get nothing.
If you make something with a predefined list like in the screenshot of Mandriva (like our beloved "Groups" in Yast), it makes it easier to search in every language. The model approach is also interesting: one model to install everything default of OpenOffice (with the translation of your locale).
My first language is spanish, so I know what you mean. As I said in my previous reply, it is my intention to have both a "text search" and a categorie/groups approach for people who knows what they want and people who wants to explore what they can get or are too lazy to type :-) What you call model approach, is somewhat already implemented on opensuse with the "patterns" filter. The appropiate language is set alright for most apps. Except the classic problem Gnome vs KDE issue. In KDE you just change your settings on KDE settings and its done. Gnome takes it settings form the $LANG enviroment variable instead of a config file. I install my personal systems with english as main system language and for my personal account I set KDE to spanish and is all right except when go to a GTK/GNOME app that starts in english. So with KDE I can have easily multilingual desktops on the same machine, but GNOME requires some hacks for the same. A wide fit all solution require more work on install and first session time. Ricardo Cornet. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le jeudi 02 avril 2009, à 21:03 -0400, Ricardo Cornet a écrit :
Except the classic problem Gnome vs KDE issue. In KDE you just change your settings on KDE settings and its done. Gnome takes it settings form the $LANG enviroment variable instead of a config file. I install my personal systems with english as main system language and for my personal account I set KDE to spanish and is all right except when go to a GTK/GNOME app that starts in english. So with KDE I can have easily multilingual desktops on the same machine, but GNOME requires some hacks for the same. A wide fit all solution require more work on install and first session time.
I'm a bit surprised -- I would expect that LANG is set when you log in (in KDE too). Note that this is really a standard way to define the language for an app. See for example: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Vincent Untz wrote:
Le jeudi 02 avril 2009, à 21:03 -0400, Ricardo Cornet a écrit :
Except the classic problem Gnome vs KDE issue. In KDE you just change your settings on KDE settings and its done. Gnome takes it settings form the $LANG enviroment variable instead of a config file. I install my personal systems with english as main system language and for my personal account I set KDE to spanish and is all right except when go to a GTK/GNOME app that starts in english. So with KDE I can have easily multilingual desktops on the same machine, but GNOME requires some hacks for the same. A wide fit all solution require more work on install and first session time.
I'm a bit surprised -- I would expect that LANG is set when you log in (in KDE too). Note that this is really a standard way to define the language for an app. See for example: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
Vincent
True. is the standard way since ancient times. Designed for command line apps. My home system have LANG=en_US.UTF-8 set and I also have LC_COLLATE to posix. Simply because that behavior is better for the command line, man pages documentation, error messages, whatever works better setting them. But why the desktop has to depend on them?. Why I can't set them differently? . Well I can change after I open a terminal, but the command line tools should not dictate graphical tools policy and viceversa. KDE people got this right, GNOME people had another opinion. Of course every process can inherit it process enviromental variables. But one realm getting on the way of the other is bothersome. To clarify, after initial system installation KDE does start in english, but it can be set permanently to be in another language just by setting KDE internal configuration. After an update this does not change, the .kde files are just the same. GNOME behavior assume that the user can only use one language on the system. That is my experience with linux distros in general for years, not just opensuse. If I'm mistaken on something please make me know. Ricardo Cornet. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Fredag den 3. april 2009 12:09:15 skrev Ricardo Cornet:
Vincent Untz wrote:
I'm a bit surprised -- I would expect that LANG is set when you log in (in KDE too). Note that this is really a standard way to define the language for an app. See for example: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
Vincent
True. is the standard way since ancient times. Designed for command line apps. My home system have LANG=en_US.UTF-8 set and I also have LC_COLLATE to posix. Simply because that behavior is better for the command line, man pages documentation, error messages, whatever works better setting them.
But why the desktop has to depend on them?. Why I can't set them differently? . Well I can change after I open a terminal, but the command line tools should not dictate graphical tools policy and viceversa. KDE people got this right, GNOME people had another opinion.
Of course every process can inherit it process enviromental variables. But one realm getting on the way of the other is bothersome.
To clarify, after initial system installation KDE does start in english, but it can be set permanently to be in another language just by setting KDE internal configuration. After an update this does not change, the .kde files are just the same. GNOME behavior assume that the user can only use one language on the system.
I think what you guys are discussing is 50% a feature for KDE and 50% a bug in KDE ;-) Of course KDE should let the language and locale be set per user, which it does. But KDE should also register and respect system settings _until_ the user tells it differently, which it doesnt quite do (in KDE4): https://bugs.kde.org/show_bug.cgi?id=176650 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le vendredi 03 avril 2009, à 06:09 -0400, Ricardo Cornet a écrit :
I'm a bit surprised -- I would expect that LANG is set when you log in (in KDE too). Note that this is really a standard way to define the language for an app. See for example: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
Vincent
True. is the standard way since ancient times. Designed for command line apps. My home system have LANG=en_US.UTF-8 set and I also have LC_COLLATE to posix. Simply because that behavior is better for the command line, man pages documentation, error messages, whatever works better setting them.
But why the desktop has to depend on them?. Why I can't set them differently?
I'd argue it's a configuration issue on your end. You should only set LANG to en_US.UTF-8 when running a shell with a prompt, since this is what your seem to be looking for.
Well I can change after I open a terminal, but the command line tools should not dictate graphical tools policy and viceversa. KDE people got this right, GNOME people had another opinion.
I don't understand your point: nobody in GNOME manually sets LANG. The user simply selects his language when logging in. It's definitely done in a graphical way. (and I'll point out that the login manager should take the default value for this setting from the value chosen during installation -- pretty sure it works with gdm, eg) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/4/3 Vincent Untz <vuntz@opensuse.org>:
Le vendredi 03 avril 2009, à 06:09 -0400, Ricardo Cornet a écrit :
I'm a bit surprised -- I would expect that LANG is set when you log in (in KDE too). Note that this is really a standard way to define the language for an app. See for example: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
Vincent
True. is the standard way since ancient times. Designed for command line apps. My home system have LANG=en_US.UTF-8 set and I also have LC_COLLATE to posix. Simply because that behavior is better for the command line, man pages documentation, error messages, whatever works better setting them.
But why the desktop has to depend on them?. Why I can't set them differently?
I'd argue it's a configuration issue on your end. You should only set LANG to en_US.UTF-8 when running a shell with a prompt, since this is what your seem to be looking for.
Well I can change after I open a terminal, but the command line tools should not dictate graphical tools policy and viceversa. KDE people got this right, GNOME people had another opinion.
I don't understand your point: nobody in GNOME manually sets LANG. The user simply selects his language when logging in. It's definitely done in a graphical way. (and I'll point out that the login manager should take the default value for this setting from the value chosen during installation -- pretty sure it works with gdm, eg) Yes that is, gdm does it but if you use kdm it won't work (don't know for XDM). I had the problem on my computer. I use the language A in KDE as first language, it is also the first language for the installation. My wife want her session, also in KDE, to be in language B. I change the language settings in KDE's GUI but all the GTK applications (Gimp, Firefox...) stay in the first language or in English (if no translation in A is available). The only solution is to either change the LANG in .profile in an editor or to install gdm (but a bit weird if you don't use Gnome as desktop).
The problem is also multilanguage. KDE permit to use fallback languages (if your basic language is translated for 70%, you can use another one than english for the other 30%). So, in both cases, you must do it by hand. Jean
Vincent
-- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Martin Schlander wrote:
Onsdag den 1. april 2009 05:57:20 skrev Ricardo Cornet:
Something I did not include in the previous mail, partly because I forgot /partly because It can be implemented independently of the usability improved minimalistic yast is a extra tab for the yast software manager.
This tab would focus on desktop applications exclusively. For example when I want to install one simple application for example openoffice, dozens of package appear, regular users are puzzled by it and don't get anywhere, and advanced users have to look out for the one right package to install or rigorous one-by-one selection.
I'd like to hear your opinions.
I think history is full of examples of trying to make things easier and more minimalistic, and things ending up more confusing complex and unreliable and/or not doing what people need.
I think that would be because many things were not well done, planned or left half-done. If the minimalistic approach for a simple way to access to services and getting things done fail is because the implementation is bad. Just as using electrical cars instead of oil fueled cars today is not practical yet due to high costs and low battery efficiency among other reasons. If it is done right I don't think anyone would complain. After all nobody forces you nor anyone else to use it. If the implementation is bad, it means I failed to make it easy and simple to use.
Instead of doing it in a tab, maybe it could be done using a filter. Similarly to how Mandriva does it. So when you start up YaST software manager by default it will only search for gui apps. I guess this could be fairly easily integrated into the existing filter structure.
Actually I thought of that, the tab is a container just to separate the packages view, from the application view. The packages view remains as always, but the application view has to way to look for apps. The classical text search and a category/groups listing/navigaton panel to navigate through the categories, sub-categories and app names with their descriptions.
Hope this image shows the Mandriva approach clearly - look at the top left combobox http://www.dedoimedo.com/images/computers/2009/mandriva-2009-software- management.jpg
Btw. as I understand it, with the software managers unlike other YaST-modules you don't get both Qt and GTK "for free". So do you plan to do this for Qt _and_ GTK, or only or the other?
Well yast does have the groups filter, but works for packages. Well, I may have make a ncurses version as well :-). Well since is a desktop app finder/installer/manager both qt and gtk version would be necessary, but would be front-ends to some of the same code. After all if you do a zypper ref && zypper up, the desktop-apps must be upgraded as well and I would need to touch some of libzypp which works for both gui-environments. Ricardo Cornet -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (6)
-
Benji Weber -
Jean Cayron -
Luiz Fernando Ranghetti -
Martin Schlander -
Ricardo Cornet -
Vincent Untz