Nabble - Gnome - Desktop - Dev

gnome.org outage: Dec 12, 13

2009-12-09T08:35:58Z

Red Hat is currently in the process of consolidating all its community
hosted servers to a single hosting facility. As part of that,
the gnome.org servers are being moved *this weekend*.

You plan on doing something other than working on GNOME this weekend, or
find a programming task that doesn't rely on access to GNOME servers.

Time
====

Start: Sat, Dec 12 approx. 1200 UTC
End: on or before Mon, Dec 14

The plan is for a 48 hour outage window; we would hope to have major
services back up and functional sooner than that.

Affected systems
================
Most gnome.org services other than ftp.gnome.org and irc.gnome.org. This
includes:

www.gnome.org
master.gnome.org
bugzilla.gnome.org
git.gnome.org
mail.gnome.org
live.gnome.org

IP Changes
==========

The gnome.org servers will all be moving to new IP addresses; in general
this will be invisible to users, but you might notice messages from SSH
in some cases. Selected new IPs:

master.gnome.org: 209.132.180.167
git.gnome.org: 209.132.180.173

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-packagekit external deps

2009-12-08T04:17:33Z

2009/12/8 Vincent Untz <vuntz@...>:
> So let's do it another way. I think you plan to release PackageKit 0.6
> in the next few weeks? If yes, I would think we can already pre-approve
> all PackageKit bumps until 0.6.0 ;-)

Excellent, thanks.

Richard.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-packagekit external deps

2009-12-08T03:24:24Z

Le mardi 08 décembre 2009, à 11:21 +0000, Richard Hughes a écrit :
> 2009/12/8 Vincent Untz <vuntz@...>:
> > In 2.28.x or 2.29.x?
>
> Just 2.29, 2.28 will continue to work with really old versions of
> PackageKit (although important bugs are fixed if you use newer
> versions)

So let's do it another way. I think you plan to release PackageKit 0.6
in the next few weeks? If yes, I would think we can already pre-approve
all PackageKit bumps until 0.6.0 ;-)

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-packagekit external deps

2009-12-08T03:21:11Z

2009/12/8 Vincent Untz <vuntz@...>:
> In 2.28.x or 2.29.x?

Just 2.29, 2.28 will continue to work with really old versions of
PackageKit (although important bugs are fixed if you use newer
versions)

>> PackageKit 0.5.5 was released yesterday, and is part of the
>> PACKAGEKIT_0_5_x series. Distros should have no real reason not to
>> upgrade, and because 0.5.5 fixes a large number of bugs compared to
>> 0.5.4, i would recommend it.
>
> Well I guess if a distro is fine updating gnome-packagekit, it's also
> fine updating PackageKit.

Right.

Richard.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-packagekit external deps

2009-12-08T03:02:14Z

Le mardi 08 décembre 2009, à 10:44 +0000, Richard Hughes a écrit :
> To fix some bugs, I've raised the gnome-packagekit dep on PackageKit
> to 0.5.5. I'm asking for retrospective permission to do so as I've
> been poked by a couple of people now.

In 2.28.x or 2.29.x?

> PackageKit 0.5.5 was released yesterday, and is part of the
> PACKAGEKIT_0_5_x series. Distros should have no real reason not to
> upgrade, and because 0.5.5 fixes a large number of bugs compared to
> 0.5.4, i would recommend it.

Well I guess if a distro is fine updating gnome-packagekit, it's also
fine updating PackageKit.

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-packagekit external deps

2009-12-08T02:44:56Z

To fix some bugs, I've raised the gnome-packagekit dep on PackageKit
to 0.5.5. I'm asking for retrospective permission to do so as I've
been poked by a couple of people now.

PackageKit 0.5.5 was released yesterday, and is part of the
PACKAGEKIT_0_5_x series. Distros should have no real reason not to
upgrade, and because 0.5.5 fixes a large number of bugs compared to
0.5.4, i would recommend it.

Okay for me to update the external deps wiki?

Thanks (and sorry for not asking first...),

Richard.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: advice drawing without window decoration

2009-12-04T11:52:26Z

On Fri, 2009-12-04 at 19:41 +0000, Richard Henwood wrote:
> Hi All,
>
> I want to develop a 'desktop companion' in a similar vein to:
> http://www.tversoft.com/company/DeskSoft/DesktopPlant.html
> It will 'grow' according to the output of my auditing code.
>
> Can anyone advise how I can draw to the gnome window system without window decoration (i'm currently using gtk.Window.set_decorated). I'm not sure about my window not appearing on the panel...

Setting an RGBA colormap on the window is required and set the colormap
on construct and screen change, then add and use gtk.DrawingArea for
drawing, then drawing to the DrawingArea will have a transparent
background.... Take a look at the pydock hack I did here;
http://www.qdh.org.uk/wordpress/?p=242

what you're interested in basically is the window and the
gtk.DrawingArea derived classes... Sorry its in python but you should be
able to get the idea.

Hope this helps,
K,

> And I suspect that there is a 'right' way to do this - maybe along the lines of how my update manager tastefully alerts me to updates?
>
> Any ideas much appreciated,
> richard
>
>
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

advice drawing without window decoration

2009-12-04T11:41:18Z

Hi All,

I want to develop a 'desktop companion' in a similar vein to:
http://www.tversoft.com/company/DeskSoft/DesktopPlant.html
It will 'grow' according to the output of my auditing code.

Can anyone advise how I can draw to the gnome window system without window decoration (i'm currently using gtk.Window.set_decorated). I'm not sure about my window not appearing on the panel...

And I suspect that there is a 'right' way to do this - maybe along the lines of how my update manager tastefully alerts me to updates?

Any ideas much appreciated,
richard

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 2.29.3 released

2009-12-03T08:39:36Z

GNOME 2.29.3 Development Release
========================

The third development release of GNOME 2.29/2.30 development cycle is here !

To compile GNOME 2.29.3, you can the jhbuild [1] modulesets [2] (which
use the exact tarball versions from the official release):

[1] http://library.gnome.org/devel/jhbuild/
[2] http://download.gnome.org/teams/releng/2.29.3/

The release notes that describe the changes between 2.29.2 and 2.29.3
are available. Go read them to learn all the goodness of this release:

platform - http://download.gnome.org/platform/2.29/2.29.3/NEWS
desktop - http://download.gnome.org/desktop/2.29/2.29.3/NEWS
admin - http://download.gnome.org/admin/2.29/2.29.3/NEWS
bindings - http://download.gnome.org/bindings/2.29/2.29.3/NEWS
devtools - http://download.gnome.org/devtools/2.29/2.29.3/NEWS

The GNOME 2.29.3 release is available here:

platform sources - http://download.gnome.org/platform/2.29/2.29.3/
desktop sources - http://download.gnome.org/desktop/2.29/2.29.3/
admin sources - http://download.gnome.org/admin/2.29/2.29.3/
bindings sources - http://download.gnome.org/bindings/2.29/2.29.3/
devtools sources - http://download.gnome.org/devtools/2.29/2.29.3/

WARNING! WARNING! WARNING!
--------------------------

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate
development status.

For more information about 2.29, the full schedules, the official
modules list and the proposed modules list, please see our 2.29 page:
http://www.gnome.org/start/unstable/

Also take a look at the abbreviated schedule reminder page at:
http://live.gnome.org/Schedule

We hope you'll love it,

The GNOME Release Team
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Advice requested on deprecating AT-SPI/CORBA

2009-12-02T11:14:17Z

Le mercredi 02 décembre 2009, à 09:57 -0500, Willie Walker a écrit :

> >>As a potential solution, we can modify the AT-SPI/CORBA *.desktop
> >>file to key off of a new gconf key,
> >>/desktop/gnome/interface/at-spi-corba. The existing
> >>/desktop/gnome/interface/accessibility key will be used everywhere
> >>else as normal, but this new key will be used to specify whether the
> >>old or new infrastructure should be used.
> >
> >Does this mean that the registryd will start and stay if the value of
> >at-spi-corba is true, but the value of accessibility is false?
>
> No - the /desktop/gnome/interface/accessibility should still be the
> gating factor. /desktop/gnome/interface/at-spi-corba will be used
> just to decide which one should be used if
> /desktop/gnome/interface/accessibility is True.

Cool!

[... moving to python stuff...]

> Yep - it's a big hack. The idea is that it should be an interim
> solution for the GNOME 2.29.x series only. The goal is that by
> GNOME 2.30, we can dump the CORBA solution completely.

Good to know! Although, hrm, wouldn't gnome-mag and gok still need it?
(sorry if you have to explain to me the same thing again and again :/)

> I tried monkeying around with ways to isolate this to just a pyatspi
> solution. The idea I was chasing would be that the CORBA solution
> would be installed under pyatspi-corba and the D-Bus solution would
> be installed under pyatspi-dbus. There would be some sort of
> 'pyatspi' shim module that would effectively do a "import
> pyatspi-dbus as pyatspi" or "import pyatspi-corba as pyatspi" based
> upon the gconf setting. My Python chops weren't strong enough to
> figure that out. Any thoughts on this?

Hrm, what about first checking if we're running in a X session? This is
still a hack, but it at least removes the gconftool-2 call in many cases
where we wouldn't want this to happen.

Something like:

import commands, os, sys; os.environ.has_key('DISPLAY') and (commands.getoutput('gconftool-2 --get /desktop/gnome/interface/at-spi-corba') == 'true') and sys.path.insert(0, '@prefix@/lib/python@PYTHON_VERSION@/site-packages/pyatspi-corba')

I'm sure some python heroes could find a non-hacky solution ;-)

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Advice requested on deprecating AT-SPI/CORBA

2009-12-02T06:57:28Z

> (Hrm, I'm obviously late ;-))

:-)

>> As a potential solution, we can modify the AT-SPI/CORBA *.desktop
>> file to key off of a new gconf key,
>> /desktop/gnome/interface/at-spi-corba. The existing
>> /desktop/gnome/interface/accessibility key will be used everywhere
>> else as normal, but this new key will be used to specify whether the
>> old or new infrastructure should be used.
>
> Does this mean that the registryd will start and stay if the value of
> at-spi-corba is true, but the value of accessibility is false?

No - the /desktop/gnome/interface/accessibility should still be the
gating factor. /desktop/gnome/interface/at-spi-corba will be used just
to decide which one should be used if
/desktop/gnome/interface/accessibility is True.

>> As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install
>> its pyatspi module under site-packages/pyatspi-corba/pyatspi and put
>> a site-packages/pyatspi-corba.pth file in place. The
>> pyatspi-corba.pth file would prepend Python's sys.path with
>> site-packages/pyatspi-corba if a new gconf key,
>> /desktop/gnome/interface/at-spi-corba (the same one described
>> above), was True. This is admittedly a big hack, but the thinking
>> is that we really only want this scaffolding in place until we
>> finally pull the plug in AT-SPI/CORBA.
>
> I see that this is implemented with a gconftool-2 call in
> pyatspi-corba.pth. As you point out, this is a big hack :-) My main
> worry here is that every time python is started, this is called. It's
> probably not that much of an issue if this is happening from within a
> GNOME session, but I wouldn't want scripts run by sysadmins to have
> this, for example.
>
> I can't think of a much better hack right now, but this is probobably
> something we should investigate...

Yep - it's a big hack. The idea is that it should be an interim
solution for the GNOME 2.29.x series only. The goal is that by GNOME
2.30, we can dump the CORBA solution completely.

I tried monkeying around with ways to isolate this to just a pyatspi
solution. The idea I was chasing would be that the CORBA solution would
be installed under pyatspi-corba and the D-Bus solution would be
installed under pyatspi-dbus. There would be some sort of 'pyatspi'
shim module that would effectively do a "import pyatspi-dbus as pyatspi"
or "import pyatspi-corba as pyatspi" based upon the gconf setting. My
Python chops weren't strong enough to figure that out. Any thoughts on
this?

Will

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Advice requested on deprecating AT-SPI/CORBA

2009-12-02T06:40:19Z

Hey,

Le mercredi 21 octobre 2009, à 12:57 -0400, Willie Walker a écrit :
> Hi All:
>
> We're slated to have the AT-SPI/D-Bus stuff in place for 2.29.2.
> Things are chugging away and looking positive. I have some
> questions about some approaches we are going to take and would like
> some opinions and advice for how to do it better if your stomach is
> weakened by the proposed approaches. In other words, speak up now
> before it's too late. ;-)

(Hrm, I'm obviously late ;-))

> Not launching both registryd's at once
> --------------------------------------

[...]

> As a potential solution, we can modify the AT-SPI/CORBA *.desktop
> file to key off of a new gconf key,
> /desktop/gnome/interface/at-spi-corba. The existing
> /desktop/gnome/interface/accessibility key will be used everywhere
> else as normal, but this new key will be used to specify whether the
> old or new infrastructure should be used.

Does this mean that the registryd will start and stay if the value of
at-spi-corba is true, but the value of accessibility is false?

> pyatspi
> -------

[...]

> As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install
> its pyatspi module under site-packages/pyatspi-corba/pyatspi and put
> a site-packages/pyatspi-corba.pth file in place. The
> pyatspi-corba.pth file would prepend Python's sys.path with
> site-packages/pyatspi-corba if a new gconf key,
> /desktop/gnome/interface/at-spi-corba (the same one described
> above), was True. This is admittedly a big hack, but the thinking
> is that we really only want this scaffolding in place until we
> finally pull the plug in AT-SPI/CORBA.

I see that this is implemented with a gconftool-2 call in
pyatspi-corba.pth. As you point out, this is a big hack :-) My main
worry here is that every time python is started, this is called. It's
probably not that much of an issue if this is happening from within a
GNOME session, but I wouldn't want scripts run by sysadmins to have
this, for example.

I can't think of a much better hack right now, but this is probobably
something we should investigate...

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Video Hackfest conclusions

2009-12-01T06:59:20Z

Sorry for the late reply to this. I'm curious how closed captioning
and/or subtitles will be rolled into this. Do you video folks have any
thoughts?

I'm also curious if we might also want to consider some sort of gconf
setting that says "give me closed captioning" that any video player can
check and honor.

Will

Benjamin Otte wrote:

> Hi,
>
> As you may be aware, we held a video hackfest last week in Barcelona.
> Developers met to discuss how best to improve GPU support for video
> applications. See http://gstreamer.freedesktop.org/wiki/VideoHackfest
> for more details. In particular, you might be interested in the notes
> some people took while the hackfest was going on. These can be found
> at http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
>
> What follows is the results we arrived at after the hackfest. They are
> taken from http://gstreamer.freedesktop.org/wiki/VideoHackfest/Conclusions
> but certainly deserve wide circulation. We're interested in any
> comments (or questions) you might have about them, so please don't
> heistate to reply.
>
> If you do reply, please make sure to reduce the recipient list appropriately.
>
> Cheers,
> Benjamin,
>
> on behalf of all hackfest paticipants.
>
>
> == YUV in pixman ==
> It has been a goal for a while to make video a first-class citizen in
> the image stack. A concrete API proposal on how to integrate video
> into pixman was reached and reviewed.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/YCbCr_Formats
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/pixman
> Actions:
> * GStreamer developers to provide a specification of important YUV formats
> * Write implementation
>
> == YUV in Cairo ==
> To make it easy for applications to use these different formats, the
> Cairo API needs to be extended to allow them. A proposal does exist
> and has been reviewed, details need to be finalized.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo
> Actions:
> * Finalize proposal
> * Write implementation
>
> == locking in Cairo ==
> GStreamer takes a lot of freedom in deciding which threads to schedule
> elements in. Most hardware backends however require proper
> serialization of commands. The current gst-plugins-cairo and
> gst-plugins-gl code provide different, but ugly ways to achieve this.
> Cairo's internal thread safety guarantees match these requirements
> very well. But the different Cairo backends don't always keep these
> guarantees. Interaction with these locking mechanisms from outside
> applications is not possible yet either.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo
> Actions:
> * Improve Cairo backend implementations, in particular X11 and GL
> * Expose Cairo's locking API to allow interaction with it
> * Write testcases to squash bugs
>
> == locking in Mesa ==
> The GLX specification does not allow binding the same GLX context in
> multiple threads at the same time. This is a requirement for both
> Cairo's and GStreamer's threading model. An extension was proposed and
> initial code developed to support this requirement in the same way as
> Apple's GL does by default. Windows does not support this and would
> require potentially expensive fallback code.
> Links:
> * http://people.freedesktop.org/~anholt/MESA_multithread_makecurrent.spec
> Actions:
> * Get review for suggested extension and include it in future Mesa releases
> * Make Windows developers investigate the situation
>
> == switch GStreamer to Cairo as default video transport model ==
> The current approach to handling video in GStreamer is very outdated.
> It does not allow hw-accelerated buffers nor does it provide a unified
> API to modify video buffers, which leads to fragmentation and
> duplication. It was agreed that using Cairo to provide an abstraction
> as a drawing API and abstraction over different backends was a good
> idea.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
> * http://cgit.freedesktop.org/~company/gst-plugins-cairo
> Actions:
> * Rework gst-plugins-cairo to match improvements listed in previous points
> * Get more review on API and to avoid regressions
> * Merge into gst-plugins-base
> * Switch plugins gradually to use new Cairo code
>
> == gst-plugins-gl ==
> The general consensus was that gst-plugins-gl is a hack. It was
> necessary in the past to get things to work, but is not a good way
> forward. However, the functionality or performance provided by the
> current elements needs to continue working. Developers shared the
> opinion that gst-plugins-cairo with cairo-gl surfaces is the best way
> to achieve this.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
> Actions:
> * Get review of cairo-gl/gst-plugins-cairo code from gst-plugins-gl developers
> * Port gst-plugins-gl elements to use Cairo early to ensure required
> features are available
>
> == XRenderPutImage ==
> Currently there is no way to upload video data to the X server for
> later use. The XV extension is not sufficient for anything more
> complicated than a simple video player.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo
> Actions:
> * Figure out the best way to move YUV data into hw-accelerated Cairo
> surfaces (GL vs X)
> * Possibly draft an extension to XRender to handle this in the no-GL case
>
> == JIT in Pixman ==
> ORC was investigated as a potential JIT for pixman. A lot of talk has
> happened, but no clear conclusions were reached. The idea to share a
> JIT with Mesa's GLSL stack was also brought up.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
> Actions:
> * Continue investigating JIT options
> * Prototype ORC integration into Pixman
>
> == Video decoding Acceleration ==
> Hardware video decoding is a feature that everybody is very excited
> about and wants to integrate into GStreamer as soon as possible. But
> developers feel that the current APIs available - the focus was on
> VAAPI and VDPAU - to do hardware acceleration fail to integrate well.
> No developer managed to create even demo-quality integration with
> gst-plugins-cairo, even though quite a few tried. In particular, both
> VDPAU and VAAPI...
>
> ... do not integrate with existing frameworks
> Both libraries fail to use (or allow easy conversion to) existing
> objects (GEM handles, GL textures, ...) but only provide access to an
> encapsulation. This makes it hard for a flexible framework like
> GStreamer to make use of its features without limiting itself.
>
> ... do not have a clear scope
> In particular VDPAU advertises itself as a video playback framework
> using hardware acceleration. Unfortunately, they both limit themselves
> to only the formats and functionalities supported by the hardware and
> see fullscreen video playback as the single usecase. This needlessly
> complicates integration with existing frameworks
>
> ... provide a very complicated API
> For decoding video, an API like provided by libtheora, libmpeg2 or
> even ffmpeg is very simple and allows easy integration with both the
> demuxing and the postprocessing/display side. VAAPI and VDPAU require
> complex setups and preprocessing of the data to work properly.
>
> ... overlap with GL functionality
> It was felt that a lot of processing features provided by these
> libraries are equally well available using shaders in GL or by
> providing GL extensions. It was unclear why it is necessary to use a
> separate way to do this.
>
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest?action=AttachFile&do=view&target=VAinGST.pdf
> Actions:
> * Get in contact with developers of the APIs
> * Encourage revision of public
> * Work closer together in integrating the provided functionality into GStreamer
>
> = Timeline =
> The end goal of all of this is to get the code into users' hands
> quickly, but allow a smooth and non-disrupting upgrade. Desired dates
> have been put forth to achieve this:
> * End of January: release new versions of Cairo and Pixman that
> contain the new APIs reuired by GStreamer
> * End of March: X server and Mesa releases are due - make sure the
> required Mesa extension is part of this. Ideally XrenderPutImage would
> be included, too.
> * April/May, after next Fedora/Ubuntu releases: Merge Cairo support
> into gst-plugins-base and start porting elements to it. Encourage
> application developers (browser, Flash players) to make use of the new
> APIs
> * October: another Fedora/Ubuntu release that switches all users to
> the new APIs
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-27T13:55:41Z

On Thu, Nov 26, 2009 at 2:27 PM, Jud Craft wrote:
> Does every GTK program that makes use of a text-entry in a side-pane
> face this dilemma? Like MonoDevelop or Brasero?
>

I'll go ahead and add this: although it has an amazing amount of
keyboard shortcuts, MonoDevelop's field navigation is pretty much
dysfunctional.

Ctrl-tab is used to switch between documents (which I appreciate, if
only the rest wasn't conflicted with it), which means that you cannot
tab out of the editor pane. In addition, only one of the frames seem
to be accessible (Solution, for me), and hidden panes (errors,
breakpoints) can be triggered with their shortcuts, but not accessed
with Tab.

These non-editor panes also seem to eat tab at inconvenient times,
meaning that field navigation halts and is completely useless.

If keyboard navigation is handled at the toolkit level, how can there
be so much inconsistency between nearly every app? Is the basic
functionality really not useful enough so as to require custom hacks?
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Branch notifications

2009-11-27T05:48:37Z

On Wed, Nov 25, 2009 at 01:03:13PM -0600, Shaun McCance wrote:
> The only potential problem is that the emails come from your username
> @src.gnome.org. I know shaunm@... gets to my inbox, and I think
> shaunm@... does as well. But do we have proper aliases set
> up for everybody who has git access?

@src.gnome.org is automatically forwarded for as long as you have access
to Git. Same address is used as your @gnome.org (for those people who
have that).

--
Regards,
Olav
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Branch notifications

2009-11-27T05:45:58Z

On Tue, Nov 24, 2009 at 04:43:10PM +0000, Calum Benson wrote:
> >Since the git migration, we have automatic notifications for
> >any branch using the standard gnome-MAJOR-MINOR scheme. They
> >go out to release-team, gnome-doc-list, and gnome-i18n.
>
> Could the mail also go to the developer who made the branch, for
> reassurance/confirmation? It's quite conceivable they won't be on
> any of those mailing lists, so will never see the automatic
> notification otherwise.

done, see gitadmin-bin module for the script (gnome-post-receive-email)

--
Regards,
Olav
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-27T04:24:16Z

Hi!

> Isn't it very obvious that a menuitem that is bound to the
> 'copy-from-textview' action will always copy from the text view ? If
> you want a different behaviour, maybe you should bind the menuitem to
> a 'copy-from-focussed-widget' action instead...

We kind of do this. But it doesn't work fully that way and the reason is
that we cannot do a GTK_IS_SOURCE_VIEW() somewhere in the code because
gtksourceview isn't linked to the whole application but just to some
module. And as such we cannot split things between GtkTextView and
GtkSourceView...

Regards,
Johannes

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

signature.asc (204 bytes) Download Attachment

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T12:30:41Z

On Thu, Nov 26, 2009 at 2:53 PM, Johannes Schmid <jhs@...> wrote:

>
> To explain the source of the problem a bit: The menu shortcut for "Copy"
> is "Ctrl-C". Normally the keybindings for the upper most widget/window
> is computed first which means that if you press "Ctrl-C" it will
> activate the menu item. But "Copy" is bound to call
> gtk_text_view_copy_clipboard() and as such, even if you have a GtkEntry
> focused this will copy the selected text from the GtkTextView and not
> from the GtkEntry. That is usually not what you want and as such a hack
> was introduced to reverse the chain and call the top-most widget after
> all other widgets, which usually means that the key-press has already
> been handled before it reaches there.

Isn't it very obvious that a menuitem that is bound to the
'copy-from-textview' action will always copy from the text view ? If
you want a different behaviour, maybe you should bind the menuitem to
a 'copy-from-focussed-widget' action instead...
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T11:53:19Z

Hi!

Am Donnerstag, den 26.11.2009, 14:27 -0500 schrieb Jud Craft:
> Does every GTK program that makes use of a text-entry in a side-pane
> face this dilemma? Like MonoDevelop or Brasero?

Anjuta for examples does. We haven't added a hack like gedit that but
actually I am planning to do so because otherwise it is even more
annoying.

To explain the source of the problem a bit: The menu shortcut for "Copy"
is "Ctrl-C". Normally the keybindings for the upper most widget/window
is computed first which means that if you press "Ctrl-C" it will
activate the menu item. But "Copy" is bound to call
gtk_text_view_copy_clipboard() and as such, even if you have a GtkEntry
focused this will copy the selected text from the GtkTextView and not
from the GtkEntry. That is usually not what you want and as such a hack
was introduced to reverse the chain and call the top-most widget after
all other widgets, which usually means that the key-press has already
been handled before it reaches there.

Regards,
Johannes

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

signature.asc (204 bytes) Download Attachment

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T11:27:02Z

On Thu, Nov 26, 2009 at 11:33 AM, Paolo Borelli wrote:
> Well, I'd be happy to drop such hacks, but right now it is a "less of
> two evils" situation... without that hack pressing ctrl+v in a text
> entry in the sidepane would be pasted in the main text area. I'd love to
> have a good solution to this issue in gtk 3 :-)

This reveals my already apparent utter cluelessness in GTK UI
programming, but why does "making sure text is pasted in the right
field" also mean that "ctrl-tab can't exit the toolbar"?

This is obviously an ancillary question, but I'm very curious.

Does every GTK program that makes use of a text-entry in a side-pane
face this dilemma? Like MonoDevelop or Brasero?
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T11:22:53Z

On Wed, Nov 25, 2009 at 8:19 PM, Matthias Clasen wrote:
> If you pay attention to where this discussion started, you will see
> that that is not the case. The starting point was a request to
> increase conflicting uses of Ctrl-Tab...

Yes, I see. But I am merely saying that, sparing the tab-interface
thing, ctrl-tab is GNOME's current "conflict-free" way to navigate
fields. If GNOME continues to use ctrl-pageup/down for tab
management, it will stay this way. [I'm actually in favor of the
ctrl-tab for tab management, myself. But at the moment, no change has
been made.]

I mentioned earlier that maybe this field-nav shortcut could be super-tab.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T10:13:08Z

Op donderdag 26-11-2009 om 17:33 uur [tijdzone +0100], schreef Paolo
Borelli:
> Il giorno mer, 25/11/2009 alle 20.32 -0500, Matthias Clasen ha scritto:
> > This is a side-effect of gedit disagreeing with the GTK key handling
> > model, and doing its own thing. See gedit_window_key_press_event for
> > details.
> Well, I'd be happy to drop such hacks, but right now it is a "less of
> two evils" situation... without that hack pressing ctrl+v in a text
> entry in the sidepane would be pasted in the main text area. I'd love to
> have a good solution to this issue in gtk 3 :-)

Yes, a DOM event model as exposed to JavaScript in web browsers would be
welcome: event bubbling would allow clean handling of all kinds of
events.

— Wouter

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

signature.asc (205 bytes) Download Attachment

Re: on application focus navigation (was: On ctrl-tab)

2009-11-26T08:33:47Z

Il giorno mer, 25/11/2009 alle 20.32 -0500, Matthias Clasen ha scritto:

> On Wed, Nov 25, 2009 at 3:22 PM, Jud Craft <craftjml@...> wrote:
>
> > Use ctrl-tab repeatedly in Gedit. You can exit the text entry, you
> > can enter the toolbar. You can move through any toolbar button. But
> > when you reach the last one, you cannot leave the toolbar with
> > ctrl-tab.
> >
> > So, from what you're telling me, I deduce that
> >
> > 1. The text entry only lets you -enter- it with Tab, not ctrl-tab.
> > If this is indeed the case, I have many thoughts.
> >
> > 2. Gedit's toolbar is messed up.
> >
>
> This is a side-effect of gedit disagreeing with the GTK key handling
> model, and doing its own thing. See gedit_window_key_press_event for
> details.

Well, I'd be happy to drop such hacks, but right now it is a "less of
two evils" situation... without that hack pressing ctrl+v in a text
entry in the sidepane would be pasted in the main text area. I'd love to
have a good solution to this issue in gtk 3 :-)

Ciao

Paolo

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T17:32:37Z

On Wed, Nov 25, 2009 at 3:22 PM, Jud Craft <craftjml@...> wrote:

> Use ctrl-tab repeatedly in Gedit. You can exit the text entry, you
> can enter the toolbar. You can move through any toolbar button. But
> when you reach the last one, you cannot leave the toolbar with
> ctrl-tab.
>
> So, from what you're telling me, I deduce that
>
> 1. The text entry only lets you -enter- it with Tab, not ctrl-tab.
> If this is indeed the case, I have many thoughts.
>
> 2. Gedit's toolbar is messed up.
>

This is a side-effect of gedit disagreeing with the GTK key handling
model, and doing its own thing. See gedit_window_key_press_event for
details.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T17:30:37Z

On 25 Nov 2009, at 19:32, Jud Craft wrote:

> So, if you don't mind my asking -- where exactly is the canonical
> reference for GNOME GUI design? I assume you mean the GNOME HCI
> Guidelines 2.2 are unmaintained? Or is it just kind of touch-and-go?

Well, "unmaintained" suggests nobody's looking after it at all, which isn't strictly true. We do still look at the bugs that come in, but it's true we don't fix very many of them in the stable version of the HIG. With GNOME 3.0 looming ever larger, I'd rather we devoted our efforts to taking a step back and producing a new set of UI design documents from the ground up.

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T17:24:08Z

On 25 Nov 2009, at 18:09, Jud Craft wrote:

> On Wed, Nov 25, 2009 at 12:58 PM, Andre Klapper wrote:
>> http://bugzilla.gnome.org/enter_bug.cgi?product=HIG
>
> Ah. I formerly heard to try against GTK. I'll need to do some bug
> changes, but I don't see much use in a user filing a problem with the
> HIG. Is that even a good idea?

Since most keyboard navigation is implemented at the toolkit level, it's not really discussed in the HIG, so it probably won't get a lot of traction there.

To be honest, you might be better having this discussion over on the gnome-accessibility-list, as there's a lot of people over there who rely on good keynav to use GNOME at all, and who would certainly need to approve any changes in this area.

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T17:19:41Z

On Wed, Nov 25, 2009 at 3:22 PM, Jud Craft <craftjml@...> wrote:

>> Unless you invent a keyboard that has reserved keys for focus
>> navigation, there will always be conflicts.
>
> GNOME has one. It uses ctrl-tab as the focus-nav shortcut to avoid
> conflicts. It should be used more consistently, unlike in Gedit
> (can't leave toolbar) and Rhythmbox (can't navigate toolbar).

If you pay attention to where this discussion started, you will see
that that is not the case. The starting point was a request to
increase conflicting uses of Ctrl-Tab...
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [gst-devel] Video Hackfest conclusions

2009-11-25T15:09:11Z

On 11/25/2009 05:56 AM, Farkas Levente wrote:

> thanks for the conclusion. one thing which would be very useful (for me
> and may be others).
> Fedora/Ubuntu is a very fast moving target, but i understood it as a
> good target for gstreamer. although some people (like me) would like to
> use a more robust os like rhel/centos. but currently it's not possible
> to update gstreamer to newer version on rhel/centos since gstreamer
> depend on glib/gtk which is too old in rhel for newer gstreamer.
> as (probably) rhel-6 will be out in 2010 it means that version of
> glib/gtk/cairo which will be in rhel-6 will remain for many years in the
> rhel/centos-6.
> so if i dare to ask that gtk/glib/cairo version in rhel-6 should have to
> enough for these features. ie. rise the required gtk/glib/cairo version
> in the current gstreamer to be enough for later version. otherwise these
> features can't be used in rhel-6 for many years.
> thanks in advance.

As far as I know RHEL6 will be based on Fedora 12 which was released a few
days ago.

behdad

> regards.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation

2009-11-25T13:45:00Z

On 11/25/2009 02:32 PM, Jud Craft wrote:

> So, if you don't mind my asking -- where exactly is the canonical
> reference for GNOME GUI design? I assume you mean the GNOME HCI
> Guidelines 2.2 are unmaintained? Or is it just kind of touch-and-go?

I don't know. I don't hack on any GUI. I hope would answer this though.

behdad
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Branch notifications

2009-11-25T12:31:21Z

On Wed, 2009-11-25 at 14:26 -0600, Shaun McCance wrote:

> On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote:
> > On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote:
> >
> > > The only potential problem is that the emails come from your username
> > > @src.gnome.org. I know shaunm@... gets to my inbox, and I think
> > > shaunm@... does as well. But do we have proper aliases set
> > > up for everybody who has git access?
> >
> > Could you simply use the email in the commit instead?
>
> No, I don't think that will work, because branches in git
> don't result in new commits.

Ok, actually, that's a very good point.

--
Danielle Madeley
Software Developer, Collabora Ltd. Melbourne, Australia

www.collabora.co.uk

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Branch notifications

2009-11-25T12:30:14Z

On Wed, 2009-11-25 at 17:27 -0300, Germán Póo-Caamaño wrote:

Can we assume then that that email will work, since they've chosen it.

--
Danielle Madeley
Software Developer, Collabora Ltd. Melbourne, Australia

www.collabora.co.uk

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Branch notifications

2009-11-25T12:27:19Z

On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote:
> On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote:
>
> > The only potential problem is that the emails come from your username
> > @src.gnome.org. I know shaunm@... gets to my inbox, and I think
> > shaunm@... does as well. But do we have proper aliases set
> > up for everybody who has git access?
>
> Could you simply use the email in the commit instead?

I think Shaun refers to that email.

In order to get an idea, you can take some modules and try something
like:

$ git log --pretty=format:"%cd <%ce> <%ae>" | grep "\.gnome.org"

You will find a lot of (svn|src).gnome.org emails from authors and
committers.

Regards,

--
Germán Póo-Caamaño
Concepción - Chile
http://www.gnome.org/~gpoo/

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

signature.asc (204 bytes) Download Attachment

Re: Branch notifications

2009-11-25T12:26:33Z

On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote:
> On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote:
>
> > The only potential problem is that the emails come from your username
> > @src.gnome.org. I know shaunm@... gets to my inbox, and I think
> > shaunm@... does as well. But do we have proper aliases set
> > up for everybody who has git access?
>
> Could you simply use the email in the commit instead?

No, I don't think that will work, because branches in git
don't result in new commits.

--
Shaun

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T12:22:11Z

On Wed, Nov 25, 2009 at 3:06 PM, Matthias Clasen wrote:
> To clear up some of the confusion here, the difference is not how you
> can _enter_ the toolbar, it is how you can leave the widget before it.
> Gedits content pane needs to accept tab as input, thus you are
> required to use Ctrl-tab to leave it.

I hate to be presumptuous, but we're talking about the same thing. I
know you have to use ctrl-tab to leave a text-pane, and I'm okay with
that.

And I am indeed talking about -leaving- the toolbar, not entering it.

Use ctrl-tab repeatedly in Gedit. You can exit the text entry, you
can enter the toolbar. You can move through any toolbar button. But
when you reach the last one, you cannot leave the toolbar with
ctrl-tab.

So, from what you're telling me, I deduce that

1. The text entry only lets you -enter- it with Tab, not ctrl-tab.
If this is indeed the case, I have many thoughts.

2. Gedit's toolbar is messed up.

> In rhythmbox, regular tab works
> since it doesn't have to accept tab as input.

But you missed my complaint -- that in Gedit, I can use ctrl-tab to
move between buttons, but in Rhythmbox, I can't.

> Unless you invent a keyboard that has reserved keys for focus
> navigation, there will always be conflicts.

GNOME has one. It uses ctrl-tab as the focus-nav shortcut to avoid
conflicts. It should be used more consistently, unlike in Gedit
(can't leave toolbar) and Rhythmbox (can't navigate toolbar).
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: on application focus navigation (was: On ctrl-tab)

2009-11-25T12:06:14Z

On Wed, Nov 25, 2009 at 2:53 PM, Jud Craft <craftjml@...> wrote:

> On another note related to the widget-group problem, consider GEdit
> and Rhythmbox, specifically their toolbars, and arrow key navigation
> of a toolbar.
>
>
>
> In GEdit, I can enter the toolbar using tab and ctrl-tab. I can only
> exit it using tab (ctrl-tab, which should get into anything, gets
> stuck in it for some reason...). I can also use the arrow keys, which
> is pretty cool, but if you're moving through fields with ctrl-tab, I
> don't want to change over to a new shortcut.
>
> In Rhythmbox, I can enter the toolbar using tab. But, you can't
> navigate it with either tab or ctrl-tab! You have to use the darn
> arrow keys only!

To clear up some of the confusion here, the difference is not how you
can _enter_ the toolbar, it is how you can leave the widget before it.
Gedits content pane needs to accept tab as input, thus you are
required to use Ctrl-tab to leave it. In rhythmbox, regular tab works
since it doesn't have to accept tab as input.

[...]

> The only thing more frustration than multiple options for keyboard
> navigation, are multiple options that only work at certain times.
> It's frustrating enough that Tab has text-entry conflicts.

Unless you invent a keyboard that has reserved keys for focus
navigation, there will always be conflicts.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list