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.
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 change
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
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 mail in
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 are
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 applications
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 the
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
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-sudoku is hit
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
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 developed a
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
patch
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
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?
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 fault.
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#D20http://www.gnome.org/%7Ecsaavedra/news-2008-09.html#D20
Can't help but wonder, if he was just buttering us (transators) up
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 had
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 the
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 something
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 to
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
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
be
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
this?
Could
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 :
Can we
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 past the
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)
presented
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
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
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 zero if the
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. The
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 let
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
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
thing as a
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
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]
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
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)
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
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
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, maybe
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 work on
41 matches
Mail list logo
