[yast-devel] Updater applet for Gnome and KDE
The openSUSE updater is a desktop applet which shows the user the available updates (patches). It is very light and simple as the real work is done by the YaST solver. This allows us to provide one applet per desktop, much like you have a a NetworkManager applet per desktop. The KDE applet was born last year as a Google SoC project. Today I imported the opensuseupdater KDE applet sources from berlios to svn.opensuse.org/svn/zypp. The gnome applet was already in the zypp repository. There is a new wiki page for both the KDE and Gnome applet. * http://en.opensuse.org/Updater_Applet The sources for both applets are located here: * http://svn.opensuse.org/svn/zypp/trunk/updater-gnome/ * http://svn.opensuse.org/svn/zypp/branches/SuSE-Linux-10_2-Branch/updater-kde... Also, there is a work branch for the KDE applet where a major refactoring is going on to cleanup legacy code from SoC, use cmake as build system and load the backends as KDE plugins. It will become trunk once it works: http://svn.opensuse.org/svn/zypp/branches/work/updater-kde-refactoring/updat... Just email me for any question! cheers -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Duncan, Cool there is now a Gnome version, but I wonder why not make a YaST module out of it. The icon systray could be added easily, 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 (we could have a module to report security updates, that the user could print at login, or mail to him, or whatever, allowing the user to fire the patches window from there). zypper and yast-ncurses can already be combined to do this, but just a thought... Cheers, Ricardo Ter, 2007-04-10 às 13:28 +0200, Duncan Mac-Vicar Prett escreveu:
The openSUSE updater is a desktop applet which shows the user the available updates (patches). It is very light and simple as the real work is done by the YaST solver. This allows us to provide one applet per desktop, much like you have a a NetworkManager applet per desktop.
The KDE applet was born last year as a Google SoC project. Today I imported the opensuseupdater KDE applet sources from berlios to svn.opensuse.org/svn/zypp. The gnome applet was already in the zypp repository.
There is a new wiki page for both the KDE and Gnome applet. * http://en.opensuse.org/Updater_Applet
The sources for both applets are located here:
* http://svn.opensuse.org/svn/zypp/trunk/updater-gnome/ * http://svn.opensuse.org/svn/zypp/branches/SuSE-Linux-10_2-Branch/updater-kde...
Also, there is a work branch for the KDE applet where a major refactoring is going on to cleanup legacy code from SoC, use cmake as build system and load the backends as KDE plugins. It will become trunk once it works:
http://svn.opensuse.org/svn/zypp/branches/work/updater-kde-refactoring/updat...
Just email me for any question!
cheers
-- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 10 April 2007 16:58, Ricardo Cruz wrote:
Cool there is now a Gnome version, but I wonder why not make a YaST module out of it.
Because that would mean starting up a large number of things that are not really needed at that point? As a matter of fact, I really like the fact that this is a very small application that doesn't consume so many system resources.
The icon systray could be added easily,
Hm - really? How would we go about to do that? 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. The nice thing of that applet is that it's small and unobtrusive. I would very much prefer to keep it that way.
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. CU -- Stefan Hundhammer <sh@suse.de> 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 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 <sh@suse.de> 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 4/10/07, Ricardo Cruz <rpmcruz@alunos.dcc.fc.up.pt> 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. • 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. • There is a significant overhead to run the VM The entire point of the applet is a small light thing to avoid having to keep running yast2. I like ycp as much as anyone, but I don't think it is appropriate here. _ Benjamin Weber -- 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 <rpmcruz@alunos.dcc.fc.up.pt> 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
On Wednesday 11 April 2007 14:40, Ricardo Cruz wrote:
• 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,
We have them anyway if KDE is installed. There is some magic in our KDE libs that supersede the KDE file dialogs with the standard Qt file dialogs. And besides, we don't use file dialogs too heavily anyway.
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")
tooltips, etc.
Tooltips is another thing that does not in the least depend on KDE. Qt provides everything for it. But still all the texts would need to be written, proof-read, translated, and of course maintained. That's why so far we decided not to use them. Pushing the YaST2 Qt UI more towards KDE would only fuel the KDE haters flames IMHO. There is little, if anything, to be gained.
• 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,
Look at "RSS" in "top" or related tools. It does come at a cost. You don't want that running without a good reason.
but I have never done any profiling on it, so... Possibly its touching on the log files may suck at startup?
Eh - huh? No. Do an "strace". Look at what it all does. Then think twice if the log file (singular, it's only one until they get wrapped) might be of any significance.
(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.
That's a major point, too, of course.
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 :)
We should avoid doing things that affect all users just for the fun of it. In particular when it comes to make heavy use of the users' machines' resources without having a really good reason. This might heavily affect users' acceptance of our distribution. There are already those who keep claiming that SUSE distros use too many resources. We should not give them more ammunition for them to shoot at us. CU -- Stefan Hundhammer <sh@suse.de> 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
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
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. 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. CU -- Stefan Hundhammer <sh@suse.de> 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
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 <sh@suse.de> 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
Qui, 2007-04-12 às 16:03 +0100, Ricardo Cruz escreveu:
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.
So, for the technical implementation... I have opposed back then to having that done in yast-core. I would prefer it to be done by frontends. We can read system settings and it's easier for us to adjust the "database" of labels to translate. It's also cheaper in terms of architecture needed and cpu wasted, since we would have two conversions to do now. Plus, we could consider using stock items, so Yast's "Next" would be translated to GTK's "Forward". I am not really strong against implementing it this way though, if you guys want it. Does libyui has more exposure to libycp stuff that we don't and that would allow for this? How would you guys suggest we go to do this? Cheers, Ricardo -- 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
On Tuesday 10 April 2007 16:58:33 Ricardo Cruz wrote:
Hi Duncan,
Cool there is now a Gnome version, but I wonder why not make a YaST module out of it. The icon systray could be added easily, 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 (we could have a module to report security updates, that the user could print at login, or mail to him, or whatever, allowing the user to fire the patches window from there). zypper and yast-ncurses can already be combined to do this, but just a thought...
Because that would mean running y2base all the time. What I would like to see is not to launch sw_single but an easier module to apply the updates. Something more fancy and less technical. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (4)
-
Benji Weber -
Duncan Mac-Vicar Prett -
Ricardo Cruz -
Stefan Hundhammer