Re: Contribution

On Thu, 31 Aug 2006, Pat Suwalski wrote:

...

> On the project I work on, Celestia, my goal is to have a UI that is
> consistent with the Windows UI, so that it's literally a port. To that
> end, some things follow the HIG (I have dialog buttons at the bottom of
> the window as opposed to the side)

Gtk add support for alternative button orders for just this kind of use
case.  It is at least possible to have it both ways if you want.

I dont think there is any easy way to have the buttons on the side as
Adobe seems to prefer instead of at the bottom but it would be interesting
if it were possible.  It sort of goes against reading order, unless you
think of it as the next column/page but it does make good use of the
fact that screens tend to be wider than they are tall.

> and other elements from the Windows UI are kept for consistency. I think
> I've reached a fairly decent balance.

I'd be interested to know more about features on Windows you feel might
go against the Gnome HIG.  Feel free to send me a quick mail offlist if
there are any little ideas.  I'd like to think you can have it both ways
but I would be interested to identify cases where you cannot, since there
may be ways to improve the HIG or suggest a different approach that works
better for both platforms.

--

-- 

Bundling all translations into release tarball

Hi,

There are many translations committed into cvs, yet there is no
corresponding entry in LINGUAS or ALL_LINGUAS. 99.9% of
them is due to lack of such knowledge or forgetfulness instead
of intentionally not adding them. So I'm going ahead and add
them into (ALL_)LINGUAS for lib platform and desktop.

To developers: If it causes any build breakage, please feel free
to flame me so that I can fix them and/or email corresponding
language maintainers, instead of silently eliminating the entry.
Fixing error is always better than hiding them. Though I don't
expect problems to occur because po files should have been
checked before entering cvs.

To translators: please remember to add the code representing
your language into po/LINGUAS, or in the ALL_LINGUAS
line in configure.in/configure.ac; otherwise translations WOULD
NOT be bundled into tarball. If any of the translation
shouldn't be bundled, please tell me too.

The po files with missing LINGUAS entries are attached with
this email.

Best,
Abel
--

-- 
Abel Cheung   (GPG Key: 0xC67186FF)
Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF
--------------------------------------------------------------------

Re: Bundling all translations into release tarball

On 9/1/06, Abel Cheung <abelcheung <at> gmail.com> wrote:
> There are many translations committed into cvs, yet there is no
> corresponding entry in LINGUAS or ALL_LINGUAS. 99.9% of
> them is due to lack of such knowledge or forgetfulness instead
> of intentionally not adding them. So I'm going ahead and add
> them into (ALL_)LINGUAS for lib platform and desktop.

My script somehow clobbered po/ChangeLog for the modules,
now fixing.

Abel

>
> To developers: If it causes any build breakage, please feel free
> to flame me so that I can fix them and/or email corresponding
> language maintainers, instead of silently eliminating the entry.
> Fixing error is always better than hiding them. Though I don't
> expect problems to occur because po files should have been
> checked before entering cvs.
>
> To translators: please remember to add the code representing
> your language into po/LINGUAS, or in the ALL_LINGUAS
> line in configure.in/configure.ac; otherwise translations WOULD
> NOT be bundled into tarball. If any of the translation
> shouldn't be bundled, please tell me too.
>
> The po files with missing LINGUAS entries are attached with
> this email.
>
> Best,

Re: Bundling all translations into release tarball

Hi Abel,

As per your mail I have checked the Malayalam (ml.po) entries in LINGUAS in
-evolution
-gnome-mag
-gnopernicus
In all the above files ml po entries are already present.

Regards
Ani Peter
Malayalam Translator

Abel Cheung wrote:
> Hi,
>
> There are many translations committed into cvs, yet there is no
> corresponding entry in LINGUAS or ALL_LINGUAS. 99.9% of
> them is due to lack of such knowledge or forgetfulness instead
> of intentionally not adding them. So I'm going ahead and add
> them into (ALL_)LINGUAS for lib platform and desktop.
>
> To developers: If it causes any build breakage, please feel free
> to flame me so that I can fix them and/or email corresponding
> language maintainers, instead of silently eliminating the entry.
> Fixing error is always better than hiding them. Though I don't
> expect problems to occur because po files should have been
> checked before entering cvs.
>
> To translators: please remember to add the code representing
> your language into po/LINGUAS, or in the ALL_LINGUAS

How can I get the default X display depth?

Hi Guys,

I failed to get display depth by gdk_rgb_get_visual().

1. I set my X display as depth 8.
#xdypinfo | grep depth
depth of root window:    8 planes

2.Then, I create a new pixmap on 8-bit using the code,
pixmap = gdk_pixmap_new (drawable, width, height,
gdk_rgb_get_visual()->depth);

Strangely, I find the value returned by gdk_rgb_get_visual()->depth is
always 24, NOT 8. I'm using gnome 2.6 and gtk+-2.4.9 on solaris. Who
know how can I get correct default depth? 

Thanks,
-Simon

Re: Contribution

On Fri, 2006-09-01 at 00:47 +0100, Alan Horkan wrote:
> On Thu, 31 Aug 2006, Pat Suwalski wrote:
> 
> ...
> 
> > On the project I work on, Celestia, my goal is to have a UI that is
> > consistent with the Windows UI, so that it's literally a port. To that
> > end, some things follow the HIG (I have dialog buttons at the bottom of
> > the window as opposed to the side)
> 
> Gtk add support for alternative button orders for just this kind of use
> case.  It is at least possible to have it both ways if you want.

Actually, that's not the point of alternate button order support; the
point of the alternate button ordering setting in GTK+ is to be able
to create a GTK+ application that runs in a Windows or KDE environment
and has button ordering consistent with the platform, including for
the standard dialogs where the buttons are created by GTK+, not by the
application.

I would consider it in poor taste for an app running within the GNOME
desktop to switch to the alternate button order; users are going to
be quite confused if some GTK+ apps running within GNOME have different
button orders for the standard dialogs than others.

					- Owen

Re: Contribution

On Fri, 2006-09-01 at 15:49 -0400, Owen Taylor wrote:
> On Fri, 2006-09-01 at 00:47 +0100, Alan Horkan wrote:
> > On Thu, 31 Aug 2006, Pat Suwalski wrote:
> > 
> > ...
> > 
> > > On the project I work on, Celestia, my goal is to have a UI that is
> > > consistent with the Windows UI, so that it's literally a port. To that
> > > end, some things follow the HIG (I have dialog buttons at the bottom of
> > > the window as opposed to the side)
> > 
> > Gtk add support for alternative button orders for just this kind of use
> > case.  It is at least possible to have it both ways if you want.
> 
> Actually, that's not the point of alternate button order support; the
> point of the alternate button ordering setting in GTK+ is to be able
> to create a GTK+ application that runs in a Windows or KDE environment
> and has button ordering consistent with the platform, including for
> the standard dialogs where the buttons are created by GTK+, not by the
> application.
> 
> I would consider it in poor taste for an app running within the GNOME
> desktop to switch to the alternate button order; users are going to
> be quite confused if some GTK+ apps running within GNOME have different
> button orders for the standard dialogs than others.

I think what Alan was saying was that GTK+ supports this so
that applications can have Gnome button order under Gnome
and Windows button order under Windows, so that Pat doesn't
have to use Windows button order in Gnome (or vice versa).

Re: Clarius

Le mardi 29 août 2006 à 18:20 -0300, Evandro Fernandes Giovanini a
écrit :
> Clearlooks is still available, it's installed by the gtk-engines
> package.

How about the metacity theme?

I'm all with Shaun's rant. This is the kind of thing that makes upgrades
difficult. I'll have to provide compatibility symlinks in gnome-themes
2.16 to avoid a mess for people upgrading.
--

-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette <at> ens-lyon.org
`. `'                        joss <at> debian.org
  `-  Debian GNU/Linux -- The power of freedom

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

Re: Contribution

On Fri, 1 Sep 2006, Owen Taylor wrote:

> Date: Fri, 01 Sep 2006 15:49:03 -0400
> From: Owen Taylor <otaylor <at> redhat.com>
> To: Alan Horkan <horkana <at> maths.tcd.ie>
> Cc: Pat Suwalski <pat <at> suwalski.net>, desktop-devel-list <at> gnome.org
> Subject: Re: Contribution
>
> On Fri, 2006-09-01 at 00:47 +0100, Alan Horkan wrote:
> > On Thu, 31 Aug 2006, Pat Suwalski wrote:
> >
> > ...
> >
> > > On the project I work on, Celestia, my goal is to have a UI that is
> > > consistent with the Windows UI, so that it's literally a port. To that
> > > end, some things follow the HIG (I have dialog buttons at the bottom of
> > > the window as opposed to the side)
> >
> > Gtk add support for alternative button orders for just this kind of use
> > case.  It is at least possible to have it both ways if you want.
>
> Actually, that's not the point of alternate button order support; the
> point of the alternate button ordering setting in GTK+ is to be able
> to create a GTK+ application that runs in a Windows or KDE environment
> and has button ordering consistent with the platform, including for
> the standard dialogs where the buttons are created by GTK+, not by the
> application.

sorry I misread it at first thinking he wasn't following the standard

Re: Clarius

Em Sáb, 2006-09-02 às 00:43 +0200, Josselin Mouette escreveu:
> Le mardi 29 août 2006 à 18:20 -0300, Evandro Fernandes Giovanini a
> écrit :
> > Clearlooks is still available, it's installed by the gtk-engines
> > package.
> 
> How about the metacity theme?
> 

The metacity theme never changed. A Clarius gtk theme was created, and
the Clearlooks metatheme was modified to use it instead of the
Clearlooks gtk theme.

This has been reverted now so 2.16 won't have the Clarius theme.

Cheers,
Evandro

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