Hello, I've just installed and tried it because it's not installed by default by alpha 5 GNOME one cd install. It is different if compared to the Qt version, but the general usage is quite simple. There are some issue however, that I think has to be addressed: * It builds the list of packages every time you switch visualisation. For example switching from "Patterns" to "Plain list" requires some time to rebuild the lists of packages, while under the QT version it is immediate. * If a package is installed, it is shown both in the Available column and in the Installed column, which is confusing. Probably this is an alternative to the Refresh function present in the QT version, but it should be made explicit. * There's no way to immediately understand if there's a new version of a package (no highlight). * There's no way to "Taboo" a package (or I didn't find it). * There's no way to select a whole list of packages. To be honest it's possible to select it by using SHIFT+CLICK, but it's not exactly amazing. * Also, a cosmetic improvement would be to show the disk space usage permanently, maybe removing the tabs and showing disk usage and sources list in two boxes at the bottom of the main window. But this is a minor issue. With kind regards, Alberto -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org

Il giorno ven, 29/06/2007 alle 18.52 +0200, Alberto Passalacqua ha scritto:

Another note. The Firewall module, has a continuously blinking "Back" button, "current status" label, check button (activate at boot) and "Start firewall now" button.

Is it continuously checking the status of the firewall?

Same blinking issue with the sudo module. Regards, A. -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org

Ricardo Cruz wrote:

Sex, 2007-06-29 às 15:35 +0200, Andreas Jaeger escreveu:

...

Ricardo Cruz <rpmcruz@alunos.dcc.fc.up.pt> writes:

...

Hi guys,

Anybody wants to comment on yast-gtk package selector? In particular the splitted pools? could you point to some screenshots, please?

The goal here is to get feedback from people that are actually using it (it is on factory and the alphas), but sure, you can have a look at it here: http://en.opensuse.org/YaST2-GTK

Cheers, Ricardo

...

...

We got some criticism with regard to it, and are evaluating if changes should be made for 10.3. The main complains seem to be that they find it to be different and confusing. We are particularly looking for feedback of people that have been using it.

Cheers, Ricardo Andreas

Hi Ricardo, Personally I like the 'System Services' display but would suggest that you replace the run level columns with a single one stating Run Levels. Then for each service have a csv list of run levels the particular service is going to run at. In addition I would include more od a description of what the service does/is used for. The Package Selector window is also good, but to me needs improvement/changing: 1. Swop the columns of installed and available software as people normally want to know what they have first before selecting an upgrade to it. 2. What about resolving package dependencies if an update needs a newer version of a dependency? My comments as you asked for feedback :) Regards Hylton -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org

Hi, that`s cool stuff! I just like to make a few remarks onto it: Runlevel: * What does the "simple mode" look like? Software Package Selector: * upgrade/remove should be either add/remove or upgrade/downgrade * the search should be on top of the list, simple because the details of the package should be close to the list of packages * I wonder what is hidden under advanced? * Where is the status of a packages shown (e.g. lock,...)? * What are the two triangles in the available software list for? I hope, I will find some time to test this on my own :-) Enjoy, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org

Sáb, 2007-06-30 às 08:48 +0200, Hylton Conacher (ZR1HPC) escreveu:

Hi Ricardo,

Personally I like the 'System Services' display but would suggest that you replace the run level columns with a single one stating Run Levels. Then for each service have a csv list of run levels the particular service is going to run at. In addition I would include more od a description of what the service does/is used for.

The system services interface is not specific to yast-gtk [1]; all tools will feature the same interface -- though the way its rendered and some widgets may differ. The only specifics are the selector's step of the package and patch management. [1] compare it to the qt one: /usr/lib/YaST2/bin/y2base runlevel.ycp qt

The Package Selector window is also good, but to me needs improvement/changing: 1. Swop the columns of installed and available software as people normally want to know what they have first before selecting an upgrade to it.

That can be done -- but Alberto voted against -- anyone want to make themselves heard and uneven the voting? :)

2. What about resolving package dependencies if an update needs a newer version of a dependency?

In the package changes list that pops up once you press Apply, it should show other packages that will be installed as a result, as nodes (this may not be accurate though). If there are conflicts, you will be asked to resolve them in a dialog identical to that of yast-qt. But yes, dependencies aren't reflected while you're "playing" with the packages. We probably want to re-code the storage model, and we will fix that. Cheers, Ricardo

My comments as you asked for feedback :)

Regards Hylton

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

Seg, 2007-07-09 às 09:32 +0200, Joerg Kress escreveu:

On Thu, 2007-07-05 at 17:09 +0100, Ricardo Cruz wrote:

...

...

The Package Selector window is also good, but to me needs improvement/changing: 1. Swop the columns of installed and available software as people normally want to know what they have first before selecting an upgrade to it.

That can be done -- but Alberto voted against -- anyone want to make themselves heard and uneven the voting? :) Well, I'm sorry to tell you. But which column makes more sense on which side, seems to be driven by what I want to achieve.

Yep, I would say people judge interface layouts based on their perception of what the main purpose of the interface is. That's why you have debates on music players whether the central widget should be the playlist or information on the music being played. In our case, their position and size relatively to the window is identical, and I find this to be merely a first impression thing, that people get used pretty quickly, so I don't put the same importance on it, as you seem to. I don't feel this is a flaw, certainly not to the point that could possibly render the approach unworkable.

It was fun to realize ;-) So I can't uneven the vote.

But seriously. I think, a lot of people will have a similar feeling at some point. If you want to operate on your existing packages, one might want this list on the left. If you rather want to search for new software, it might be the pool that needs to be on the left. That's the main reason for me, why the 2-list approach might not work. But I'm happy to try it with our users for the next release and get some more data from them (i.e. feedback on whether it works for them).

Most of the points have already been raised: * Don't keep installed packages in the list of installable packages. It confuses (though this has been improved in the latest version, where the install/upgrade button changes its label).

Could do, but it seems like people just aren't understanding, at least at first, the approach used, so we could try to make that better explicit. The Available pool should probably be labeled differently; "Repositories Packages"? We could also make entries more humanly-readable: "X version 1 is installed" - "X new version 2 is available at repo1". A one-to-one entry approach might also be more clear and allow for better syncing: "X is not installed" - "X version 1 is available at repo1".

* Some way to mark different states of a package (installed is latest, installed has update available, installed is newer than pool)

The second one seems nice; lets highlight the version number. The others don't seem important enough to bother the user; we can of course make it explicit by offering some filter (ie. show me packages that are no longer available in the repositories). Anyway, I would need to know use cases.

* A way to manipulate the lists (maybe a menu), to restrict the list to packages in a certain state or of a certain kind and than be able to operate on this restricted list on the whole (partially done with the "View Packages" field when selecting languages. We now have 4 possible selections, maybe it's time to switch to a drop-down menu.

Not sure what you are thinking of, but sounds interesting. :)

* List packages by source (I use this very often to check packages from build service).

We could have an actual view mode for sources (aka repos)... We do have something that I would think it better, since it integrates with the view modes, and that could become part of the filters you talk on the other point. In the Advanced expander, you can choose the package repos you want the pool to be build from. I would rather improve this than to add another view mode, since this lets you work on the existing views...

* Mark packages and install their -devel, -debug, whatever packages.

Thats probably undesirable; some users may not even have compilers installed, so that would drag all that stuff... What we do not do, and yast-qt can, is to propagate dependencies as you install stuff. If you install "gtk-devel", "gtk" will of course also be installed; you should be told about it once you hit Accept, but it wouldn't be marked as such in the selector. We would need a more complete storage model to offer this. It seems that Zypp changes package statuses, not offering a way to listen to those changes, so we need to actively query for statuses and match that with the ones on our storage. We probably also want to work on this to move away from Zypp's uni-dimensional pool, and structure packages better, so we can build models in no time.

In the end, even if we stick to the two column approach, the GTK+ front end should be feature equivalent with the Qt front end.

If people want to we can offer a more yast-qt similar interface as an option. GTK+ ensures we keep the data splitted from the list/tree widget, so we would only need to touch interface code. Still, we have some Zypp code on the interface callbacks, so I would want to work on the storage first, and make it a bridge for Zypp. Cheers, Ricardo

Cheers

-- Jörg Kreß <jkress@suse.de> YaST2 Development _________________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

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