Ter, 2007-04-10 às 17:01 +0200, Stefan Hundhammer escreveu:

On Tuesday 10 April 2007 16:58, Ricardo Cruz wrote:

...

The icon systray could be added easily,

Hm - really? How would we go about to do that?

Just have a UI::OpenDialog flag for that... It would be then up to the frontends to implement it (which would be trivial in GTK; but I dunno if support for that is only available through KDE libs for qt...).

Frankly, I'd hate to have a large y2base process running with everything that comes with it every time I log in. I'd simply get rid of that thing right away - for good.

Could this be really a problem? It would be idle the all time, and y2base seems pretty speedy at starting.

The nice thing of that applet is that it's small and unobtrusive. I would very much prefer to keep it that way.

It could be kept small. We don't need to use the Wizard and force some big size...

...

and the table/tree should be made more flexible anyway. We would get both interfaces for free, plus we can make some hooks for the terminal easier

What kind of terminal (text mode) user would really want that kind of application to be started upon login? And when and how would we do that? Only on the console? Surely not with every ssh login and/or with every xterm/konsole/$TERMINAL_EMULATOR_OF_YOUR_CHOICE.

I am pretty sure the vast majority of text mode users would not like that.

Surely we could have it only really check for updates every X minutes, in a similar way to what the systray module would... And notice I mean it to just print a line. It would be up to you to fire the thing. It was just a thought anyway. Just seems like a waste of time to maintain two interfaces, for Gnome and KDE. Cheers, Ricardo

CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany

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

Ter, 2007-04-10 às 16:53 +0100, Benji Weber escreveu:

On 4/10/07, Ricardo Cruz wrote:

...

It was just a thought anyway. Just seems like a waste of time to maintain two interfaces, for Gnome and KDE.

• We don't have a yast2-kde yet, only a yast2-qt.

We probably should, now that we have GTK for Gnome folks. We could use KDE file dialogs, and we could push things like icons on buttons, tooltips, etc. Checked and Qt 4 does have support for system tray icons though.

• Using ycp takes away a lot of the flexibility in UI design. I really don't think anything like we have now is possible with ycp without doing a lot of changes to the yast toolkits which rather defeats any timesaving you might have.

I have only seen the screenshot. From it, it seems we need to obsolete the current table/tree by something more generic, which may be quite some work because it touches quite a few areas. I'm surprised people talk about the systray icon; that's the piece of cake part (if it weren't because the only way to change the icon is through the wizard, we might not even need to touch the API).

• There is a significant overhead to run the VM

I hear you. The Mono usage in Gnome makes me cripple. ;) I can live with Python because I can see clear advantages for both the programmer and the user (really nice to poke at its skeleton at run-time ;)). I personally never noticed any y2base overhead, but I have never done any profiling on it, so... Possibly its touching on the log files may suck at startup? (of course, we could fix it...) I guess the big point here: * The work is done. If it ain't broken, don't fix it. But if it ever gets broken, I think you guys should consider it.

The entire point of the applet is a small light thing to avoid having to keep running yast2.

Is it really an applet or just a system tray icon (supporting an applet in YCP would be tough)? Anyway, we can of course just have the little icon written in C and having it firing a YCP program at will, possibly even checking for updates through a YCP module too.

I like ycp as much as anyone, but I don't think it is appropriate here.

Maybe. I would personally like to see it stretched a little bit :) Cheers, Ricardo

_ Benjamin Weber

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

Qua, 2007-04-11 às 14:56 +0200, Stefan Hundhammer escreveu:

On Wednesday 11 April 2007 14:40, Ricardo Cruz wrote:

...

and we could push things like icons on buttons,

We already have everything in place for that. It's not a technical issue, it's more an issue of providing all the icons and have it consistent. It wouldn't do to have some buttons with icons and most others not.

http://forgeftp.novell.com///yast/doc/SL10.2/tdg/PushButton_widget.html

("IconButton")

Back to this subject... I think we have already agreed in having stock icons implicitly set. Developers use familiar strings, so we should take advantage of that and avoid having to re-write stuff. Already asked the following in awhile, could you guys pass it to someone that knows his way through the core? Someone suggested letting the interface know of the untranslated string. This would be good enough for us and would avoid touching any module. Is this doable though? Yast can re-translate the interface at the fly... Is this done by a re-parsing, or is YLocale and stuff kept alive? If so, could we have a reference from the YCPString to it? Thanks, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Qui, 2007-04-12 às 14:49 +0200, Stefan Hundhammer escreveu:

On Wednesday 11 April 2007 20:05, Ricardo Cruz wrote:

...

Back to this subject... I think we have already agreed in having stock icons implicitly set.

I recall a discussion where we agreed that some things are technically feasible, like automatically looking up icons for a number of known button labels. The question back then, however, was if it is desirable to do that half-way, in effect having some buttons with icons and many others without.

I'm sure most Gnome and KDE developers disagree with you, with regard to describe it as "half-way", since both desktops provide icons for ordinary buttons. At least in GTK, you aren't even supposed to create buttons for actions like Ok, Close, Send, etc based on a label, but rather based on a stock item. Depending on system/user settings or the context, GTK sets a label and/or an icon and/or shortcut. The reason for having icons for ordinary action buttons and not others is that the user is more familiar to those, so it makes little sense to force him to read them all the time. By using red/green colors on icons, you can even avoid him to press "Abort" by accident. On the other hand, an icon on an non-ordinary button might actually make the user loose focus.

IIRC there was no conclusion to that; the discussion simply died down.

That's really a usability issue. The usability specialists should have a say with that, and then we will need a decision whether or not the additional work (and thus cost) for maintaining the icons (add new ones as new modules get written) are justified.

We don't need to, neither should we, as it would totally suck with regard to desktop integration or the user's setup. yast-gtk would use the following icons, possibly plus Gnome ones: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html For yast-qt, I'm sure KDE libs offer something like that or you should be able to digg them directly from the disk. Both, should check system's configuration to see if the user wants them to display icons on ordinary buttons. Cheers, Ricardo

CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany

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

On Wednesday 11 April 2007 14:40:31 Ricardo Cruz wrote:

tooltips, etc. Checked and Qt 4 does have support for system tray icons though.

Qt has support for tray icons back on 2.x series or even 1.x. I would, the day YaST becomes usable from every language as a framework. But for now, everything requires doing bindings to make things available to YCP.

I hear you. The Mono usage in Gnome makes me cripple. ;) I can live with Python because I can see clear advantages for both the programmer and the user (really nice to poke at its skeleton at run-time ;)). I personally never noticed any y2base overhead, but I have never done any profiling on it, so... Possibly its touching on the log files may suck at startup? (of course, we could fix it...)

If we could use Python or Ruby here, I would agree because I have seen the benefits other distributions got using them for small tools. But general applications using the YaST facilities become non-natural as soon you need anything else than a module. Some day may be YaST is usable from any language, and then, it will make sense. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org