Re: What will replace bonobo?

On Mon, 2009-01-12 at 18:30 -0500, "Andrés G. Aragoneses" wrote:
> DBUS

Dbus is not a direct replacement for bonobo.

There is no exact replacement of bonobo as such. However, various
technologies can be used for some things that bonobo can do. DBus can
for instance be used for low bandwidth IPC.

However, the main usecase of bonobo, which is embedding one application
in another (say mine-sweeper in gnumeric, or (slighly more useful) a dia
diagram in gnumeric) just is not used all that much. So, the lack of a
direct replacement is not a large problem. The few apps that require
this can keep using bonobo.

I don't know what the current plan for bonobo use in the panel is, but a
replacement could probably use a simple wrapper around GtkPlug/GtkSocket
if it needs out of process applets.

Re: What will replace bonobo?

Do you have any suggestions on how to remove the bonoboUI dependency in
gnome-panel without affecting most panel applets?

It is possible to use panel_applet_get_control in an applet to obtain
the bonobo control and do fancy stuff, but I don't know if anyone is
actually doing so.

Regards,

Yu
On Tue, 2009-02-03 at 09:48 +0100, Alexander Larsson wrote:
>  I don't know what the current plan for bonobo use in the panel is,
> but a
> replacement could probably use a simple wrapper around
> GtkPlug/GtkSocket
> if it needs out of process applet

Re: What will replace bonobo?

On Tue, 2009-02-03 at 03:54 -0500, Yu Feng wrote:
> Do you have any suggestions on how to remove the bonoboUI dependency in
> gnome-panel without affecting most panel applets?
> 
> It is possible to use panel_applet_get_control in an applet to obtain
> the bonobo control and do fancy stuff, but I don't know if anyone is
> actually doing so.

I don't think you can do that, so such a change would require breaking
the applet API of course.

[Announce] GNOME Global Menu 0.7.3 is released.

Dear friends,

We are glad to announce the release of GNOME Global Menu 0.7.3.

Global Menu is the globally-shared menu bar of all applications launched
in your desktop session.

In this release, we bring you the further polished

gnome-globalmenu 0.7.3 

svn checkout http://gnome2-globalmenu.googlecode.com/svn/tags/v0.7.3 

Downloads: 

http://code.google.com/p/gnome2-globalmenu/downloads/list?can=2&q=0.7.3 

      * Improved XFCE Plugin 
              * (1) dependency to gmenu removed. 
              * (2) border (1 pixel at topmost) (need to be verified) 
      * Improved Switcher on 
              * (1) application name detection 
              * (2) menu layout 
              * (3) Rebased the switcher on top of libgnomenu, making it
                much faster.
      * libgnomenu.so is separately installed 
      * libgnomenu is gir-ready under namespace Gnomenu, configure with
        --enable-gir. 
      * Gracefully loading and unloading the gtk module 

Re: [Announce] GNOME Global Menu 0.7.3 is released.

Yu Feng <rainwoodman <at> gmail.com> writes:

> Dear friends,
>
> We are glad to announce the release of GNOME Global Menu 0.7.3.
>
> Global Menu is the globally-shared menu bar of all applications launched
> in your desktop session.
>
> In this release, we bring you the further polished
>
> gnome-globalmenu 0.7.3 
>
> svn checkout http://gnome2-globalmenu.googlecode.com/svn/tags/v0.7.3 
>
> Downloads: 
>
> http://code.google.com/p/gnome2-globalmenu/downloads/list?can=2&q=0.7.3 
>

I'm writing currently pl_PL.po for thus app. However:
1. I'm nearly sure that the some translations are included into standard
(such as close).
2. Instead of "Home Page" please use "Home Webpage" - I was nearly sure
that it means that but I had to check it in code.
3. More comments in po sometimes could be helpful. For example there is
XML in the pot file. Is it an error or should it be transleted? And what
should be translated? I guess that _-prefixed elements - but I know the
gettext from programmer's point of view - don't expect every translator

Interaction with Gnome desktop

_______________________________________________
gnome-devel-list mailing list
gnome-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Re: Interaction with Gnome desktop

2009-02-05 klockan 02:38 skrev Kiril:
> I am new to Gnome and I am looking for some way to interact with the
> desktop, more specifically to be able to lock / unlock it, start
> screensaver, shutdown, hibernate,log off.
> Any ideas will be highly appreciated.

Look at the gnome-screensaver-command application and the DBus API it
invokes, and at the gnome-sessession-save application.

    — Wouter

_______________________________________________
gnome-devel-list mailing list
gnome-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Re: Interaction with Gnome desktop

_______________________________________________
gnome-devel-list mailing list
gnome-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Re: Interaction with Gnome desktop

2009-02-05 klockan 17:21 skrev Kiril:
> Should I prefer DBus?
> I started looking at Xlib.
> Which one is better?

To interact with modern Gnome desktop components, you should definitely go
for the DBus APIs. I'm not sure what you want to do, but the programs I
mentioned in my previous mail already seem to do what you described.

    — Wouter

_______________________________________________
gnome-devel-list mailing list
gnome-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Dragging and dropping windows and a standard application/x-wnck-window-id ?

I am about to throw together a little hack for Metacity which would
allow someone to drag and drop a window - as in X's dnd protocol - by
grabbing its menu icon / emblem. This would correspond to dragging a
window from workspace to workspace via libwnck's task list applet. I
think that type of functionality could enable some neat avenues for
window management which we don't have right now since this way the user
can clearly select a window and, in a sense, place it in another
application. Right now the user is limited to simply moving it around
within the window manager.

Possibilities, in order of likelihood:

      * Intuitive link between items on the window list applet and the
        windows they reflect. (Some day let's make these the same
        thing...)
      * Drag a window into a dock to "iconify" it.
      * Drag a window into a black hole applet which does essentially
        the same thing as xkill.
      * Drag a window into a chat window to send a screenshot or to open
        a remote desktop session showing / giving control over that
        window.
      * Drag a window so that the receiving application can determine
        other information that can be gathered from it, such as content
        (eg: document or person) that the window represents. Maybe a
        step closer to that still attractive window experiments mockup
        by the tango folks. (I like to think of application windows in
        terms of object oriented programming, where an open document in