Volker Kuhlmann escribió:

...

So with the Summer of Code over, it's time to announce the GTK+ interface for Yast (other SoCees, I would love to hear from you btw :)).

Just out of interest, what is the advantage of re-implementing yast by linking it with libgtk instead of libqt? Wouldn't the time have been better spent improving yast itself?

Greetings,

Volker

this is exactly the same question I have..really why ?

What's the advantage of having a qt and a gtk frontend for networkmanager?

What's the advantage of having KDE and gnome apps?

And having a qt and a gtk desktop at all?

See above. However, yast is neither a KDE nor a gnome app, nor does it look like either or would benefit if it did, so the whole exercise was pretty pointless as far as I can tell.

Give KDE users qt and Gnome users gkt !

Sure. Can I have a KDE gimp please? ;) Greetings, Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, Volker Kuhlmann wrote:

However, yast is neither a KDE nor a gnome app, nor does it look like either or would benefit if it did, so the whole exercise was pretty pointless as far as I can tell.

So do I.

...

Give KDE users qt and Gnome users gkt !

Sure. Can I have a KDE gimp please? ;)

No only Qt gimp. Talking about Gtk. Does anyone know a good way to get back a usable File Open/Save dialog, which Gtk used to have? - I miss a way to directly paste a Filename into the dialog. (Usually I do: (a) press "/", (b) select the string with the mouse, (c) press middle mouse button (d) press enter, (e) wait until the potentially large directory has been read, (f) press enter again. Changing (a) and (b) does not work!) - In Save as I have always have to flip open the folder browser - Opening of a file where the filepattern does not match makes also some troubles. (As I understand this dialog is the result of usability studies; somehow it does not my way of working. This completion, which pops up is also rather hidden!) Tobias --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Dňa St 23. August 2006 11:05 Volker Kuhlmann napísal:

...

So with the Summer of Code over, it's time to announce the GTK+ interface for Yast (other SoCees, I would love to hear from you btw :)).

Just out of interest, what is the advantage of re-implementing yast by linking it with libgtk instead of libqt? Wouldn't the time have been better spent improving yast itself?

This was done as Google Summer of Code project. It gives us several interesting advantages: - native Gtk frontend will much better integrate with GNOME (sad, but true, even after all those years with freedesktop.org) - a new look on the YaST libraries from a fresh developer already uncovered several bugs and shortcomings in the YaST generic UI code Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

But: Many users have serious problems with the software management, i.e. the package management and especially the patch management. I'm _not_ talking about functionality bugs here, but really the user interface.

The users are trying and trying and trying to find out which patches are already installed and which ones they need, and they fail. Many users simply don't get it without external help - the existing Qt frontend is too hard to use.

And now there is a new Gtk frontend that is, again, substantially different. Documenting and supporting this will be very difficult! After looking at the Gtk version of the online_update module for 3 minutes, I am still unable to determine which patches I need - there is just a list with ~100 unticked checkboxes.

Yes, one of my major complaints right now and with Zen which does close to the same thing. One thing I did notice that seems to work is by right click and selecting update all in this list or whatever (atleast on the kde list) and it only checks (sometimes by 2-3 layers deep!) only the updates which would of course mean it was installed. I'm glad this is done though, hopefully it will be included in suse 10.2! -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, Aug 23, 2006 at 06:24:30PM +0100, Ricardo Cruz wrote:

Anyway, the problem is that I thought Zypp would only report available patches :/... Now in SVN only available patches are displayed. Do you, as a user, have the need for an installed patches catalog? And btw, can you remove installed patches?

My understanding is that a patch is a kind of "assertion", i.e. it enforces that the included packages have version numbers greater than the unpatched ones. If you remove a patch, no package will change, but it will then be possible to downgrade the packages in the patch to old versions without a package conflict. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, Ricardo Cruz schrieb:

Yes, that's always nice to get. :)

OK ;-)

Now in SVN only available patches are displayed.

What does "available" in this context mean? I know, I can make a new checkout myself ;-)

Do you, as a user, have the need for an installed patches catalog?

I don't know if there's a "need" for that, but I'd like to have it - clearly distinguishable from the patches which are still needed. What I would to have like is: - A default view that presents only those patches which make sense for my system. That is, those patches that are either not yet installed, or installed, but broken (e.g. by manually downgrading a package to a lower version than the patch defines). - The default view should display only those patches described above and neither installed and fulfilled patches nor patches that don't apply to my system (e.g. because none of the base packages that makes up the patch is installed). - Optionally, an extended view that shows which patches I already have. This functionality is not "needed", but a user might want to review these (e.g. a patch broke something - this happens from time to time - and the user wants to know which patch is to blame). This should be available if possible, but not in the default view. - Difficult question: How to handle patches that are fulfilled, but not installed. This happens when the user directly installs an updated version of a package instead of installing the original version and then patching it. This is a difference technically, but the interesting question for the user is whether he needs that patch. And since the packages are up-to-date, IMHO this case should be handled as if the patch were installed although it is actually not. Fancy Idea: There could be two "pools" of patches, similar to the two "pools" in the software installer. One of them holds what I already have and the other one holds what I can get. The destinction between these must be clear and intuitive, much more than in the qt frontend.

And btw, can you remove installed patches?

That's a difficult one ;-) Neither qt YOU nor ncurses YOU provide an interface for removing installed patches, but rug and zen-remover do (not working). But this feature does not make too much sense as long as tabooing patches is not possible (with "tabooing" I mean "never ever install this patch and don't even ask" - none of the update tools supports that currently).

Sort by status? Did you mean "sort by severity"?

No. With "status" I do not mean the severity. With "status" I mean one of: (1) Not applicable (cannot be installed on this system) (2) Not needed (not installed, but fulfilled by the installed packages) (3) Already installed and fulfilled (4) Already installed and broken (reinstall needed) (5) Neither installed nor fulfilled (installation needed) The default view should include (4) and (5); an extended view should include (2) and (3); (1) does not need to be accessible from the GUI in my opinion. The severity is also important, but that is just for sorting the patches and deciding whether they are pre-selected by default. The "status" decides whether a patch is displayed _at_all_. When implementing the "pool" idea - I don't know if it's a good idea, it's just a proposal - the "is installed" pool should contain (2) and (3), the "can be installed" pool should contain (3) and (4), and (1) can be left out. The user doesn't need to see them.

I understand the feeling that a user may get information on a website that doesn't apply to his Yast frontend, but only the package selector interface is different and if we make it easy to use, such websites won't be necessary.

That's a good point. The ncurses and qt frontends were already different until SUSE 10.0 and there was never a need to explain anything. The confusion started with SUSE 10.1. So you are probably right, assuming that each frontend is easy to use on its own, they are allowed to be different.

Maybe we shouldn't offer the YOU interface and direct the user to zen-updater? I dunno, but I guess the best is to provide it and the distribution should be the disabling it, if it wants to.

Yeah, that's this well-known and problematic duplication of tools... But YOU and Zen-Updater still don't obsolete each other. For example, Zen-Updater requires root to grant _permanent_ zmd privileges when used from within a user account - without doing that, Zen-Updater refuses to do anything, while YOU accepts the root password for single sessions just fine. This is something that many users don't like about Zen-Updater because it breaks the traditional root <-> user separation. It's one of the reasons why YOU is still popular. The Zen-Tools are integrated with the desktop, YOU is integrated with the rest of YaST, and they are very different. So we still need YOU.

But aren't the problems more related with the so many choices? You have Yast, Zen, Synapitec together with the command tools, and different repository systems.

Yes, that is another problem, but a separate one. Maybe we - the users - should reconsider recommending alternative tools too intrusively. Urging users to use other tools doesn't help avoiding confusion, especially since sometimes they don't play well together. It's a complex thing that doesn't have anything to do with YaST-GTK ;-) Apart from that, YOU alone _is_ currently confusing - let's hope that the new gtk YOU becomes really cool and causes the other YOUs to become cool again as well ;-)

I dunno, but I'd really like to avoid Yast-Qt's package selector... It's unnecesarly complex and I understand why it badly needs documentation.

I'm not sure whether I get the terminology correctly here. Is it correct that the package selector is what I see when launching sw_single.ycp? If so, it's OK for me. Most of my complaints are directed against what I see when launching online_update.ycp.

Anyway, we haven't yet discussed the Yast-GTK package selector interface with the Yast team. I will start a discussion about that next week. yast-public would be the appropriate place, so if you want to register (its very low traffic): http://forge.novell.com/mailman/listinfo/yast-public

Great, of course I'd like to follow the discussion if it's public. Thanks! Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Dňa St 23. August 2006 21:06 Andreas Hanke napísal:

Hi,

Ricardo Cruz schrieb:

[snip]

...

And btw, can you remove installed patches?

That's a difficult one ;-)

Neither qt YOU nor ncurses YOU provide an interface for removing installed patches, but rug and zen-remover do (not working). But this feature does not make too much sense as long as tabooing patches is not possible (with "tabooing" I mean "never ever install this patch and don't even ask" - none of the update tools supports that currently).

What would make sense it to go for patch downgrade, e.g. patch the system to use the 1st ZYPP online patch. This is also not possible right now with zen-updater and YOU.

...

Maybe we shouldn't offer the YOU interface and direct the user to zen-updater? I dunno, but I guess the best is to provide it and the distribution should be the disabling it, if it wants to.

Yeah, that's this well-known and problematic duplication of tools... But YOU and Zen-Updater still don't obsolete each other. For example, Zen-Updater requires root to grant _permanent_ zmd privileges when used from within a user account - without doing that, Zen-Updater refuses to do anything, while YOU accepts the root password for single sessions just fine.

The idea of zen-updater is to have a tool integrated with the desktop for use. YOU is designed as a tool for power-users that want a complete control over their systems. [snip]

...

I dunno, but I'd really like to avoid Yast-Qt's package selector... It's unnecesarly complex and I understand why it badly needs documentation.

I'm not sure whether I get the terminology correctly here. Is it correct that the package selector is what I see when launching sw_single.ycp?

If so, it's OK for me. Most of my complaints are directed against what I see when launching online_update.ycp.

That's the same thing technically. There is a package selector widget that has to handle patch mode and package mode. Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org