Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> > thingy people have implemented, aiming for the 2.16 release timeframe. > > So are you asking for official inclusion of this for 2.16? Deskbar is already part of GNOME, as of 2.14. NewStuffManager is in the Deskbar 2.16 codebase, so if there are no actions to the contrary, then this will become part of GNOME 2.16. However, since being told that things like new dependencies should be announced on desktop-devel-list, the existence (and implied blessing) of NewStuffManager should at least be announced on d-d-l. But also, arguably, this is a new dependency of sorts, even if developed under the Deskbar umbrella rather than as a separate package. And there are these two questions of security and privacy - so it's a little more complicated then applying s/elementtree/NewStuffManager/ on the statement "NOTE: deskbar-applet has a tiny new dependency called elementtree". So I wrote this long e-mail to d-d-l in anticipation that the GNOME community would want to discuss this before we release (deskbar-applet + NewStuffManager) as part of 2.16. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: removing non-working things
On 7/30/06, Alan Horkan <[EMAIL PROTECTED]> wrote: > > If there is a need to fill the void, we could add a "Show icons in > > buttons" checkbox instead, since this is a feature that works reliably > > everywhere... > > Does it? Maybe it is no longer a problem anymore but a long time ago when > developers were experimenting with "show icons on buttons" things didn't > work out well for buttons with only an icon and no text label. > > Applications which had used a row of buttons without text instead of a > proper toolbar ended up with blank useless buttons. GTK+ is smarter about this now; image-only buttons will not loose their images. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: removing non-working things
On Sun, 30 Jul 2006, Matthias Clasen wrote: > Date: Sun, 30 Jul 2006 14:47:39 -0400 > From: Matthias Clasen <[EMAIL PROTECTED]> > To: desktop-devel-list@gnome.org > Subject: removing non-working things > > The gnome-ui-properties capplet contains a "Detachable toolbars" > checkbox, which has three issues: > > a) It only affects BonoboToolbars, not for regular GtkToolbars Erm are you sure? A Gtk Toolbar has to put inside a container to make it detachable which many developers dont or wont do. (Forgive me for not being able to put into more techincal terms, I know this from experimenting with various mockups in Glade rather than coding it myself where I'd need to learn the correct terminology.) I'm still hoping Gtk will have a future toolbar which will be dockable and detachable and everything but not hoping very much. There are cases like Eog where I'd like to be able to move/put the toolbar vertically when going through a set of largely tall portraite images. (Same goes for gthumb, more so because it wastes a horrific amount of vertical space with a second title bar.) I went through a stage of asking various programs to do so and be more consistent but programs such as Evince politely declined to do so, which isn't unreasonable and quite understandable because detachable toolbars in Gtk aren't much use (not to say some future toolbar setup couldn't make them more useful). > b) It does not even work correctly for bonobo toolbars (try >detaching and reattaching the evolution toolbar, for instance) I agree reattaching toolbars can be quite finnickey there was some trick like holding down Ctrl or something which made it easier to reattach things (possibly related to the window manager move window option). It would be nice if non-working thing could be fixed. > c) Even if it worked correctly everywhere, it is not a very >useful feature. Unfortunately that is quite true, even worse I've seen users (of non GTK applications with more complicated toolbars) manage to lose toolbars or accidentally hide things and be left wondering where they went. (The users didn't understand the little overflow arrows indicating hidden items.) Toolbars should not be detachable by default. Do the Gtk developers even have plans to overhaul the Toolbars into something more advanced later? Is it low on the list of priorities or is it on the list at all? Toolbars are admittedly not much use at the moment but they are not beyond hope and could probably still be improved. > So I'd like to propose that we drop this checkbox. When I went through my phase of trying to get developers to implement it consistently I met a lot of polite resistance. I came to the conclusion that it might be best to set all toolbars to Locked/Not detachable by default to at least make things consistent. Applications which wanted to allow users to rearrange the toolbars could unlock them/make them detachable if and only if the user chose something like "customize toolbars" or "unlock toolbars" which might also included other functionality such as drag and drop of toolbar items. > If there is a need to fill the void, we could add a "Show icons in > buttons" checkbox instead, since this is a feature that works reliably > everywhere... Does it? Maybe it is no longer a problem anymore but a long time ago when developers were experimenting with "show icons on buttons" things didn't work out well for buttons with only an icon and no text label. Applications which had used a row of buttons without text instead of a proper toolbar ended up with blank useless buttons. It seems some developers do not want flat toolbars and instead want their toolbar to look more 3 Dimensional and button-like, which would be a theme issue not a widget issue. (Winzip used to have an option to change the toolbar button style.) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: removing non-working things
Hey Matthias, On Sun, 2006-07-30 at 14:47 -0400, Matthias Clasen wrote: > The gnome-ui-properties capplet contains a "Detachable toolbars" > checkbox, which has three issues: > > a) It only affects BonoboToolbars, not for regular GtkToolbars Nod > b) It does not even work correctly for bonobo toolbars (try >detaching and reattaching the evolution toolbar, for instance) Wasn't that this bug? http://bugzilla.gnome.org/show_bug.cgi?id=167944 If it doesn't work properly, it's a regression. I backported this patch to a 2.8.x version of libbonoboui, and it seemed to work fine. > c) Even if it worked correctly everywhere, it is not a very >useful feature. Not useful at all. > So I'd like to propose that we drop this checkbox. > > If there is a need to fill the void, we could add a "Show icons in > buttons" checkbox instead, since this is a feature that works reliably > everywhere... I'd kill it as well. Is there a bugzill opened already? -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
removing non-working things
The gnome-ui-properties capplet contains a "Detachable toolbars" checkbox, which has three issues: a) It only affects BonoboToolbars, not for regular GtkToolbars b) It does not even work correctly for bonobo toolbars (try detaching and reattaching the evolution toolbar, for instance) c) Even if it worked correctly everywhere, it is not a very useful feature. So I'd like to propose that we drop this checkbox. If there is a need to fill the void, we could add a "Show icons in buttons" checkbox instead, since this is a feature that works reliably everywhere... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Mon, 2006-07-31 at 01:06 +1000, Nigel Tao wrote: > thingy people have implemented, aiming for the 2.16 release timeframe. So are you asking for official inclusion of this for 2.16? signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab (nautilus integration)
> In our case, when we open the properties dialog for a folder, nautilus > shows the total count of this folder. Near this place it could have a > button 'Detailed disk space analysis', which would launch baobab to scan > the selected folder. Making [the number + a little pie chart icon] clickable would be better - the user can discover it, but it's not such a vital feature that it needs to clutter Nautilus. Ed Mack ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
OK, I should have brought this up on d-d-l a month or two ago, at
least before we got all freezy, but I procrastinated. Corner me
sometime and ask for my lame excuses. Anyway, going with better late
than never...
The text below is probably best read at my blog:
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 where it has
new-fangled technologies like screenshots and links, but it's
copy'n'pasted here in case the nitpickers amongst you want to quote
stuff in any ensuing argument^Wdiscussion. 'cos it's not like d-d-l
hasn't been controversial enough in the last few weeks... :-)
Short version: There's this new easily-install-new-deskbar-plugins
thingy people have implemented, aiming for the 2.16 release timeframe.
However, it's, like, easily-download-executables-from-the-internet,
which I don't think GNOME has done before, and so the GNOME community
should have a say in whether or not we push ahead with this.
Long version (really, just go straight to
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 )
One of the things about the 2.14 deskbar-applet release was that,
although it supported third-party plug-ins, the GUI to manage them was
all-but-nonexistant. Basically, whilst you could enable and disable
installed plug-ins via the checkboxes in the preferences dialog, you
couldn't (a) find and install new plug-ins, and (b) update existing
plugins through the GUI -- both of which Firefox lets you do, for
example. Instead, you had to download a file (or download and unpack a
tarball) and copy that to a secret directory
(~/.gnome2/deskbar-applet/handlers/) -- i.e. one that you couldn't
find in nautilus.
In the last few months, Sebastian Pölsterl and the other deskbar
hackers have worked on being able to install new plug-ins through a
friendly GUI. The deskbar-applet-list mailing list discussion starts
in April, continues in May and there's also the PluginManager wiki
page. Here's the current state of play (no, this isn't finalized, yes
there are issues, which I'll touch upon at the end of the tour). First
off, there's a new Check For Updates button on the list of installed
plug-ins.
Clicking on that invokes the NewStuffManager a new (Python) program
that communicates with deskbar-applet via D-Bus. To be precise,
NewStuffManager provides the org.gnome.NewStuffManager service.
NewStuffManager is not deskbar-applet specific, and could provide any
app with update info. The app-specific part is another Python file,
deskbar-applet's spec is the only instance so far, and looks like
this:
OPTIONS = {
"repo": "http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml";,
"install-path": "~/.gnome2/deskbar-applet/handlers",
}
And note that it mentions
http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml,
which is the master list of plug-ins and their versions. The intention
is that distros can customize this URL, if they choose to. An example
snippet of that XML file looks like this:
yahoo.py
Yahoo! Search
Search Yahoo! as you type
Deskbar Team <[EMAIL PROTECTED]>
3.1.1
http://raphael.slinckx.net/deskbar/repository/yahoo.py
NewStuffManager will note that there is a new version of the Yahoo
handler, and the UI will show that it is updatable.
Clicking on Update will show a progress dialog box, and under the
hood, download the newer yahoo.py from
http://raphael.slinckx.net/deskbar/repository/, unpack the archive (if
necessary), and copy those files to the right place in the file
system: ~/.gnome2/deskbar-applet/handlers/. Note that this is the
user's installed plug-ins, not the globally-shared (and
only-writable-by-root) plug-ins at /usr/lib/deskbar-applet/handlers.
The other thing to notice is the New Extensions tab. Switching to this
tab will invoke NewStuffManager to check the master list for
installable plug-ins. It looks like this:
Again, the Install button will download and install the plug-in. There
really isn't much difference between updating existing plug-ins and
installing new ones, apart from that the user was (probably) aware of
an existing plug-in beforehand, and updating an existing plug-in might
involve an active existing plug-in.
That's what it looks like. It is indeed easier to find and install
plug-ins than before. And plug-ins rock, since they make users go, "I
rock". However, there are two very significant issues:
Security: We will be downloading arbitrary Python files, which could
be executed whenever the deskbar-applet initializes all of its
plug-ins. This could be a major security hole. Personally, it's not
that I don't trust Raphael or his web-site, or the third party
websites that he chooses to endorse, but I don't trust (the worst of)
the internet. We don't have digital signatures or other verification
mechanisms implemented yet (and GNOME 2.16 is due only a few months
from now). Auto-update (and auto--removal of obsolete files) is
another issue that should be considered - whilst it is frustrating as
a developer that users don't manually upgrade to th
Re: SVN migration, any news?
Em Dom, 2006-07-30 às 16:02 +0200, Olav Vitters escreveu: > On Sun, Jul 30, 2006 at 03:12:02AM +0200, BJörn Lindqvist wrote: > > On 7/30/06, Guilherme de S. Pastore <[EMAIL PROTECTED]> wrote: > > > Em Sáb, 2006-07-29 às 17:47 +0200, Christian Neumair escreveu: > > > > As we all know SVN migration was cancelled due to problems with the > > > > migration script [1]. Maybe somebody from the SVN migration staff could > > > > come up with a short summary of what has happened since the failed > > > > migration and whether there are any plans to pick it up anytime soon. > > > > > > Ross can probably inform the nasty details better, but we had a couple > > > of unexpected problems (such as binary files corruption) during the > > > migration, fortunately spotted soon, which made us abort and reenable > > > CVS access. > > > > Is there anything you can do to help? So that the next migration > > attempt will actually work? > > I know having a Python 2.4 rpm that installs in a different location on > RHEL3 would help a lot. Haven't found time to do this yet, but IIRC > (from what Ross told) Python 2.4 needs some newer libs than available on > RHEL3. > atrpms.net seems to have python24 packages for RHEL3. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SVN migration, any news?
On Sun, Jul 30, 2006 at 03:12:02AM +0200, BJörn Lindqvist wrote: > On 7/30/06, Guilherme de S. Pastore <[EMAIL PROTECTED]> wrote: > > Em Sáb, 2006-07-29 às 17:47 +0200, Christian Neumair escreveu: > > > As we all know SVN migration was cancelled due to problems with the > > > migration script [1]. Maybe somebody from the SVN migration staff could > > > come up with a short summary of what has happened since the failed > > > migration and whether there are any plans to pick it up anytime soon. > > > > Ross can probably inform the nasty details better, but we had a couple > > of unexpected problems (such as binary files corruption) during the > > migration, fortunately spotted soon, which made us abort and reenable > > CVS access. > > Is there anything you can do to help? So that the next migration > attempt will actually work? I know having a Python 2.4 rpm that installs in a different location on RHEL3 would help a lot. Haven't found time to do this yet, but IIRC (from what Ross told) Python 2.4 needs some newer libs than available on RHEL3. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab (nautilus integration)
On Sáb, 2006-07-29 at 10:58 -0400, Matthias Clasen wrote: > On 7/29/06, Fabio Marzocca <[EMAIL PROTECTED]> wrote: > > On 7/28/06, intech <[EMAIL PROTECTED]> wrote: > > > The thing that struct me as weird in the preferences dialog is the > > > checkbox below that list... "Enable auto-detect monitoring of home > > > directory"... I still can't figure out what that means.. > > > > ...and if you can't figure it out, why didn't you take a look at the > > documentation either on baobab's site [1] or (easier!!) in the > > application's help?? Just poress F1 in baobab... it's not hard. > > > > > > Maybe using the generic name here would be better; > while "Open with Disk usage analyzer" is clunky and > "Analyse disk usage" would be much better, it is at least > immediately clear what kind of program to expect, which > is not really the case for "Open with Baobab" We could take a cue from WinXP here: when you bring up the file properties dialog for a hard drive, a few buttons are included there that launch scandisk (file system checker), defragmenter, etc. In our case, when we open the properties dialog for a folder, nautilus shows the total count of this folder. Near this place it could have a button 'Detailed disk space analysis', which would launch baobab to scan the selected folder. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
