GOK branched for GNOME 2.24

Hi, GOK has been branched for GNOME 2.24. Development will continue in trunk. cheers, Gerd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSD should not housekeep the thumbnails

2008/9/22 Ted Gould <[EMAIL PROTECTED]>: > On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote: >> JPEG loading with libjpeg is currently really slow (the benchmark being >> Photoshop, which is really goddamn fast for JPEGs). >> >> We could totally use some liboil/profiling ninjas to wo

Re: GSD should not housekeep the thumbnails

On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote: > JPEG loading with libjpeg is currently really slow (the benchmark being > Photoshop, which is really goddamn fast for JPEGs). > > We could totally use some liboil/profiling ninjas to work on libjpeg to > make it faster. Then, mayb

Modules with no stable release for 2.24.0

Hi, Here's a quick list of modules that seem to still only have an unstable release. If you want someone to release a tarball for you, please reply. evolution-webcal 2.23.91 gconf-editor 2.23.91 gnome-backgrounds 2.23.92 gnome-control-center 2.23.90 gnome-icon-theme 2

Re: GSD should not housekeep the thumbnails

On Tue, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote: > Since 2.23.1, gnome-settings-daemon contains a housekeeping plugin that > clean the .thumbnails. Even if it looks fair, it really makes the F-spot > usage awful to the point it's basically unusable. A semi-related point: JPEG loading

BillReminder has branched

BillReminder has been branched. Development will continue on trunk and the current stable version is billreminder-0.3.2. Could someone update D-L? Cheers, -- Og B. Maciel [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmac

Ekiga branched for GNOME 2.24

Hello, I created a new branch for Ekiga 3.00 and GNOME 2.24. I also created a tag for the 3.00 release. We will continue fixing things in the GNOME 2.24 branch, and new features will be committed to TRUNK. The GNOME 2.24 branch thus contains Ekiga 3.0.x code. Thank you, -- _ Damien Sandr

mousetweaks branched for GNOME 2.24

Hello, Please, note that mousetweaks has been branched for GNOME 2.24. The new development will continue in trunk (2.25.1). Best regards, Francesco Fumanti ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mail

cheese branched

i just branched cheese for 2.24. feature development should continue on trunk, gnome-2-24 is for translations and bugfixes only. thanks! daniel -- this mail was sent using 100% recycled electrons daniel g. siegel <[EMAIL PROTECTED]> http://home

Re: Prompting for passwords on the desktop?

Note that the Windows solution to use Ctrl+Alt+Del as a Secure Attention Key is just one way to implement Trusted Path. There is no reason that the GNOME or UNIX community couldn't come up with a different and novel way to meet the same requirements. The Secure Attention Key should be viewed as

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 6:46 PM, Matthias Clasen <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 12:41 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: >> That's what I proposed. If it's != 0, force it to 0 and issue a >> warning. Spin controls have no concept of data set so there is no such >>

Re: [gdm-list] GDM trunk will be used for GNOME 2.24.

Willie: While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. I wasn't trying to spe

Re: [gdm-list] GDM trunk will be used for GNOME 2.24.

Brian, all, Do we have a "chicken-and-egg" situation here? Why do all that is necessary in GDM if we don't yet feel that accessibility on the desktop is sufficiently stable to have it on by default from the GNOME community? (so goes one argument) At the same time, if we aren't quite there y

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 12:41 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > 2008/9/22 Josselin Mouette <[EMAIL PROTECTED]>: >> The difference is that you are knowingly breaking hundreds of >> applications. You are able to fix those distributed by GNOME in a snap >> and that's all good, but you l

Re: GTK adjustement changes create incompatible behaviour between versions?

2008/9/22 Josselin Mouette <[EMAIL PROTECTED]>: > The difference is that you are knowingly breaking hundreds of > applications. You are able to fix those distributed by GNOME in a snap > and that's all good, but you let downstream distributors with hundreds > of broken applications in their hands.

Re: GTK adjustement changes create incompatible behaviour between versions?

Le samedi 20 septembre 2008 à 12:17 +0100, Emmanuele Bassi a écrit : > read this bit above again... > > > This is not true. See #307963. From the gtk 2.12 documentation for > > GtkAdjustment: > > > > "The page size of the adjustment. Note that the page-size is > > irrelevant and should be set to

Re: [gdm-list] GDM trunk will be used for GNOME 2.24.

Will: While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. I agree with you that "l

Re: GTK adjustement changes create incompatible behaviour between versions?

Le lundi 22 septembre 2008, à 16:56 +0200, Vincent Untz a écrit : > And I've created patches for quite some modules: > http://tmp.vuntz.net/adjustpatches/ > > accerciser.patch > anjuta.patch > dasher.patch > deskbar-applet.patch > eog.patch > evolution.patch > file-roller.patch > gcalctool.patch

Re: GTK adjustement changes create incompatible behaviour between versions?

2008/9/22 Davyd Madeley <[EMAIL PROTECTED]>: > I think GTK+ is now doing the right thing. I believe it would do twice the right thing if it also ignored page_size for spinenr buttons. As it is used to represent the number of data "records" (be it table rows, canvas pixels or something else) presen

gnome-themes branched

Have just branched gnome-themes for 2.24. Feature development should continue on trunk, gnome-2-24 is for translations and bugfixes only. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.s

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 5:02 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: >> dasher.patch > > This one looks like it touches some sliders instead of spin buttons, > if these behave like scrollbars then page_size should be set to the > handle length in units (as you don't want the handle to move p

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 4:56 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le lundi 22 septembre 2008, à 16:50 +0200, Patryk Zawadzki a écrit : >> On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: >> > Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : >> >>

Re: GTK adjustement changes create incompatible behaviour between versions?

Le lundi 22 septembre 2008, à 16:50 +0200, Patryk Zawadzki a écrit : > On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > > Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : > >> Can we request a global freeze break permission to fix this and only > >> thi

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : >> Can we request a global freeze break permission to fix this and only >> this? > Could work, especially since we have a list of files that might need to

Re: GDM trunk will be used for GNOME 2.24.

While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. Will Vincent Untz wrote: Le lun

Re: Prompting for passwords on the desktop?

Le lundi 22 septembre 2008 à 16:02 +0200, Dave Neary a écrit : > > I really think the good criterion is not “has focus” but some “action > > triggered by the user less than 1 second ago”. > > That seems like it'll be overly complicating any code that gets written > to handle this. I didn’t mean

Re: Prompting for passwords on the desktop?

Hi, Josselin Mouette wrote: > Le lundi 22 septembre 2008 à 11:54 +0200, Steve Frécinaux a écrit : >> We could have such a behaviour: >> >> - if the application requesting the password is focused, then show the >> modal dialog directly. >> - if not, then have an icon in the notification area or som

Re: GDM trunk will be used for GNOME 2.24.

Le lundi 22 septembre 2008, à 09:46 -0400, Matthias Clasen a écrit : > On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper <[EMAIL PROTECTED]> wrote: > > The release-team is going to use gdm trunk for GNOME 2.24. > > > > Note that most release-team members have mixed feelings. > > Entire discussion woul

Re: GDM trunk will be used for GNOME 2.24.

On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper <[EMAIL PROTECTED]> wrote: > The release-team is going to use gdm trunk for GNOME 2.24. > > Note that most release-team members have mixed feelings. > Entire discussion would have been less frustrating if gdm developers had > been more responsible to t

Re: GDM trunk will be used for GNOME 2.24.

2008/9/22 Andre Klapper <[EMAIL PROTECTED]> > The release-team is going to use gdm trunk for GNOME 2.24. Oh bay, talk about a late notice. Thanks for the info. > > > Note that most release-team members have mixed feelings. > Entire discussion would have been less frustrating if gdm developers

Re: TARBALLS DUE (before Monday 23:59 UTC!, don't forget translators!): GNOME 2.24.0 Final Release

> > > As a wise man (okay, Claudio is not that wise) said [1]: watch > svn-commits-list and see translators rocking! > [1] > http://www.gnome.org/~csaavedra/news-2008-09.html#D20 > Can't help but wonder, if he was just buttering us (transat

Tomboy branched for GNOME 2.24

Hi all, Just branched Tomboy for GNOME 2.24, to a branch named gnome-2-24 [1]. My plans for next release include: * Full Windows/Mac support * Performance improvements * Fixing some long-standing embarrassing bugs, and general polish But we haven't had our roadmap meeting yet, so we'll see what

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, 2008-09-22 at 13:50 +0200, Sebastien Bacher wrote: > Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : > > If you've called the function in GTK+ directly, you never specify a > > page_size (it doesn't make sense). If you've set a non-zero page_size, > > it's really your own

Re: GTK adjustement changes create incompatible behaviour between versions?

Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : > If you've called the function in GTK+ directly, you never specify a > page_size (it doesn't make sense). If you've set a non-zero page_size, > it's really your own fault. Hi, how do you expect the people using gtk to guess that?

Re: GDM trunk will be used for GNOME 2.24.

Le lundi 22 septembre 2008, à 02:19 +0200, Andre Klapper a écrit : > The release-team is going to use gdm trunk for GNOME 2.24. > > Note that most release-team members have mixed feelings. > Entire discussion would have been less frustrating if gdm developers had > been more responsible to the con

Re: GTK adjustement changes create incompatible behaviour between versions?

Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : > On Mon, Sep 22, 2008 at 12:19 PM, Thomas H.P. Andersen <[EMAIL PROTECTED]> > wrote: > >> Can we get a precise list of affected applications? I only tripped > >> over Inkscape so far but that's not part of GNOME and we'll likely

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, 2008-09-22 at 10:23 +0100, Ghee Teo wrote: > Davyd Madeley wrote: > > I think GTK+ is now doing the right thing. > > > > >From my understanding, this only affects UIs created with Glade (which > > has been setting a page_size of 10 -- and it seems still isn't fixed). > > > > Matt here de

Evolution branched for GNOME 2.24

Guys, I created gnome-2-24 branch for Evolution, Evolution-data-server, Evolution-Exchange and GtkHTML. http://go-evolution.org/Evo2.26 has some planned activity for GNOME 2.26. -Srini. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 12:19 PM, Thomas H.P. Andersen <[EMAIL PROTECTED]> wrote: >> Can we get a precise list of affected applications? I only tripped >> over Inkscape so far but that's not part of GNOME and we'll likely >> patch it up downstream if there's no upstream fix. > > For one gnome-sudo

Re: GTK adjustement changes create incompatible behaviour between versions?

Davyd Madeley wrote: I think GTK+ is now doing the right thing. >From my understanding, this only affects UIs created with Glade (which has been setting a page_size of 10 -- and it seems still isn't fixed). Matt here developed a workaround for this in libglade. That sets the page_size to 0 a

Re: GTK adjustement changes create incompatible behaviour between versions?

> Can we get a precise list of affected applications? I only tripped > over Inkscape so far but that's not part of GNOME and we'll likely > patch it up downstream if there's no upstream fix. For one gnome-sudoku is hit by this. I have a patch ready that will be included in 2.24.1 We should fix th

Re: GTK adjustement changes create incompatible behaviour between versions?

Patryk Zawadzki wrote: On Mon, Sep 22, 2008 at 10:12 AM, Ghee Teo <[EMAIL PROTECTED]> wrote: Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since application

Re: Prompting for passwords on the desktop?

Le lundi 22 septembre 2008 à 11:54 +0200, Steve Frécinaux a écrit : > 2008/9/18 Josselin Mouette <[EMAIL PROTECTED]>: > > One way to avoid annoying the user is to establish a line like "a > > password prompt should only pop up immediately after a user action". > > This way it appears only while you

Re: Prompting for passwords on the desktop?

2008/9/18 Josselin Mouette <[EMAIL PROTECTED]>: > One way to avoid annoying the user is to establish a line like "a > password prompt should only pop up immediately after a user action". > This way it appears only while you are expecting to type a password. > > Good behavior: you click on "send mai

Re: GTK adjustement changes create incompatible behaviour between versions?

I think GTK+ is now doing the right thing. >From my understanding, this only affects UIs created with Glade (which has been setting a page_size of 10 -- and it seems still isn't fixed). Matt here developed a workaround for this in libglade. That sets the page_size to 0 and reports a warning that

Re: GTK adjustement changes create incompatible behaviour between versions?

On Mon, Sep 22, 2008 at 10:12 AM, Ghee Teo <[EMAIL PROTECTED]> wrote: > Hi Vincent, > > While you have just announced 2.24.0 tarballs to be available for 22nd Sep. > Does this mean we are going to ship 2.24.0 without an possible resolution to > this regression? > Since applications would not have a

Re: GTK adjustement changes create incompatible behaviour between versions?

Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. I