Bug 464911

Technically tricky. because those changes need a kind of restart. It should be possible to do some changes on the fly but we would need to signal from RepoManager to the active pool.

Reassigning to yast2-gtk maintainer.

Ricardo is really the maintainer - CC him instead :-)

This is a generic UI request: probably to be assigned to Stefan, sh@novell.com .

This particular request seems tricky, but we may want to arrange libyui so that a lot of the convenience stuff at YCP modules is moved there, allowing for more flexibility in the implementation. It seems especially diselegant and unefficient how fallbacks for the optional widgets aren't provided at the libyui level.

What is this all about? What dialog is this?

In the Qt package selector, there are no properties below the repository list, so comment #4 doesn't apply here.

The YaST2 software repositories module is a YCP module maintained by lslezak.

Comment #4 about generic fallbacks in libyui I don't understand at all. It's way too generic; it's very much like "we should have better software".

If anybody can elaborate to make some sense of all this, please do so and reopen.

Stefan, this is about the repositories.ycp standalone tool, not any selector integration. I think Dunanc misunderstood it as well. Vicent is requesting we make the table editable -- at least the check marks be toggled by click.

With regard to my comment, I was just saying what a pain it is to add new widgets because it affects a lot of layers. If we could add a new widget, or extend a widget with new functionality, by just touching libyui, that would be great.

e.g. instead of methods like YOptionalWidgetFactory::hasWizard(), it seems like it would be easier if we simply created a fallback widget on createWizard() at the libyui level. No need for ycp guys to wrap it up in middle men like the Wizard module.

For this request, it seems like adding a table/controls/description widget might be an attractive solution, since this is a combination used widely through yast tools, and so we could easily leverage usability. For the text UI -- and until the GUIs catch up as well -- we would have a fallback that would be a port of the compound widget YCP modules are currently using.

Changing the enabled/disabled status via double click is there, at least in the Qt UI: A double click on a table item sends an "activated" event which the repositories module uses to toggle that enabled/disabled status.

As for a spreadsheet type table edit widget: The API for YCP for such a widget would be a nightmare. Qt (the Qt4-Lib, not the YaST2 Qt UI) has a widget that could be used. It would have to be written from scratch in the NCurses UI. I don't know about the Gtk UI.

Usability wise, in all my past experienced this would be a step back because this is the kind of widget that is easily misused. Once an editable table is there, there would be little incentive for application developers to provide a proper UI for editing whatever that table displays. Just look at how the wizard tree is currently misused as a (poor, screen space wasting and ugly) replacement for tabs.

(In reply to comment #7)
> Changing the enabled/disabled status via double click is there, at least in the
> Qt UI: A double click on a table item sends an "activated" event which the
> repositories module uses to toggle that enabled/disabled status.

So it's not possible to edit autorefresh directly in the list. That's why I opened the bug :-) It would be a simple click on the check mark. Sounds really like something I'd want to do.

> Usability wise, in all my past experienced this would be a step back because
> this is the kind of widget that is easily misused. Once an editable table is
> there, there would be little incentive for application developers to provide a
> proper UI for editing whatever that table displays. Just look at how the wizard
> tree is currently misused as a (poor, screen space wasting and ugly)
> replacement for tabs.

Hrm. I don't really agree with this argument. First, I'm pretty sure quite some users are expecting the "click on the check mark in the list should work" point. And second, the fact that people can write bad UI with a feature is orthogonal to providing the feature if it's expected -- just have guidelines and make sure people don't write bad UI.

In any case, refreshing, enabling or disabling would lead either to a very cluncky pool load, unload, sync etc, or complete restart of the package manager.

(In reply to comment #9)
> In any case, refreshing, enabling or disabling would lead either to a very
> cluncky pool load, unload, sync etc, or complete restart of the package
> manager.

I'm sorry, I don't understand your comment. I'm talking about the Software Repositories tool, where you can already change those options below the list (in the Properties section). The bug is really "make those properties editable from the list".

You can see that if you access the repository editor from within the package selector, it needs to restart the package selector after saving. The same would need to happen after any "in column" editing

But how is it different from what we have now? Those properties are already editable in the main window.

Vincent is talking about the repo manager (repositories.ycp).

It is possible to change the autorefresh state by clicking the check box below the table. He suggested changing it also by clicking directly on the table item.

The problem is that UI would need to tell more details about the event (which column was clicked in the table).

The current implementation of UI::WaitForEvent() return this map:

$["EventReason":"Activated", "EventSerialNo":8, "EventType":"WidgetEvent", "ID":`table, "WidgetClass":`Table, "WidgetID":`table]

If it would tell e.g. "Column" : 2 the repo manager would be able to detect the correct property to change (Enabled or Autorefresh).