Re: GNOME Moduleset Reorganization vs. L10N

[Kenneth Nielsen]

2010/10/18 Dimitris Glezos :
> On Mon, Oct 18, 2010 at 1:12 PM, Kenneth Nielsen  
> wrote:
>> The solution of having a translations only copy of a module in gnome
>> git, combined with some sort of automatic syncing back and forth,
>> seems to a good solution for the module maintainers that don't mind
>> having this sort of solution.
>
> I'm not sure how well this will work. The developer still needs to
> sync between the trees, and in the past developers found this very
> frustrating at times. An example is when a developer updates all PO
> files with new strings and after this he pulls translations from the
> translation branch. The merge is a nightmare (since git does a git
> merge instead of a msgmerge).
>
> The feedback we received so far is that viable solutions are two: a)
> pull&push straight to the master branch and b) not push anywhere, just
> "upload" the files somewhere and the developer will fetch them when he
> needs to.
>
>> In terms of translators this will mean
>> that they can work the way they do now, so this should automatically
>> be ok for translators*. Since it is almost an implementational
>> freebie, is should be ok to have this as the base solution, and then
>> after that determine if we want to add something else.
>>
>> So at this point, can we agree that this can be ONE acceptable
>> solution? Then we could start working setting up the framework for it
>> and actually implement it for the modules that are ok with it.
>
>> Then we can afterwards continue discussing whether we should/need to
>> add an offer for a external translation framework that is also GNOME
>> approved (e.g. Transifex, Launchpad ,).
>
> I like this step-by-step, build-on-what-we-have approach, it's very
> wise and I usually follow it as well. Admittedly, though, it has a
> (serious) disadvantage: It only accepts solutions which can build on
> top of the current way of doing things. This impedes real/radical
> change. Sometimes radically changing things is good (e.g. when you're
> in a dead-end).
>
> Currently our way of working in GTP is "based on files hosted on a
> VCS, namely git.gnome.org". The challenges are obvious and well
> explained (although they hardly constitute a dead-end). My humble
> suggestion is to take this opportunity to really think how effective
> our way of doing things is. The plan behind Tx 1.0 was to move away
> from "files hosted on a VCS" and go to "strings (not files) living in
> a web app (not vcs) which can be imported/exported freely to files".
> We had both independent projects as well as projects like GNOME behind
> the decision.
>
> It was a really, REALLY hard decision, but we are confident that it's
> the way things will work in the future and the way to go. Things like
> upstream/downstream support, translation memory, consistency,
> per-string suggestions/voting.. they're all possible now. The Q is
> whether we want to take this opportunity to really re-think how we're
> doing things, or if we're just going to shift this decision to e.g. 2
> years later. Sounds like a good BoF discussion for GUADEC. =)

Well, I agree that we should think hard and long about this at some
point, because we don't ever want to exclude ourselves from the
opportunity to make radical changes. But I really really really don't
think that the GNOME 3.0 cycle is the right time to do it.

Regards Kenneth
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: G/tkApplication

[Matthias Clasen]

On Tue, Oct 19, 2010 at 11:01 AM, Richard Hughes  wrote:
> On 19 October 2010 00:44, Ryan Lortie  wrote:
>> The upshot, though, is probably that quite some application that were
>> making use of the old GApplication have stopped working.
>
> So... what versions of gtk+ and glib should GNOME 2.91.1 tarballs be
> targeted against?
>
> Can I just skip 2.91.1 tarballs and just ask people to compile
> everything from git master?
>

Please build 2.91.1 tarballs against the GTK+ 2.91.1 tarballs that I
did before the weekend.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: G/tkApplication

[Ryan Lortie]

On Tue, 2010-10-19 at 12:05 +0100, Luis Medinas wrote:
> So now it's safe for us to use GApplication again :) ? Or there is any
> possibility things
> will change a lot during this release cycle ?
> We ported Brasero on 2.31 cycle and almost at the end we had to move back to
> unique (mostly copy&paste code).

Minor changes are likely as I receive feedback on the API.

Major changes are unlikely.

Cheers

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

Re: Help make this document complete (default GNOME keyboard shortcuts on wiki)

[Calum Benson]

On 18 Oct 2010, at 12:22, Andre Klapper wrote:

> Am Sonntag, den 17.10.2010, 23:56 +0200 schrieb Mark:
>> http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
>> It would be nice to get that list complete and accurate for _default_
>> GNOME shortcuts.
> 
> http://library.gnome.org/users/user-guide/stable/keyboard-skills.html.en

Also 


Cheeri,
Calum.

-- 
CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd.
mailto:calum.ben...@oracle.com Solaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Oracle Corp.

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

Re: G/tkApplication

[Luis Medinas]

On Tue, Oct 19, 2010 at 12:44 AM, Ryan Lortie  wrote:
> Hi,
>
> While I wasn't looking, Cody Russell gained access to my laptop and
> pushed the GApplication branch to glib master.  He admits to it, even:
>
>        http://twitter.com/bratschegnome/status/27779385082
>
> Shortly afterward he redeemed himself (and fixed the GTK build) by
> pushing the new GtkApplication code.
>
> The upshot, though, is probably that quite some application that were
> making use of the old GApplication have stopped working.
>
> My recommendation is to check out this small example application that
> I've included in Gtk:
>
>        http://git.gnome.org/browse/gtk
>        +/tree/gtk/tests/gtk-example-application.c
>
> The actions stuff is not implemented in the new GApplication yet, but it
> will be coming soon (probably this week, since we're all at the hackfest
> together).  I don't think anybody is currently heavily depending on that
> for functionality at this point...
>
> The docs could probably also use some love at this point.  I'll be on
> that tomorrow, probably.
>
> If you need any help with fixing your apps, please ping me on IRC or
> ping someone else you know is at the hackfest and have them give me a
> poke.
>
> Sorry for the disruption.
>
So now it's safe for us to use GApplication again :) ? Or there is any
possibility things
will change a lot during this release cycle ?
We ported Brasero on 2.31 cycle and almost at the end we had to move back to
unique (mostly copy&paste code).

Thanks
Luis
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: G/tkApplication

[Bastien Nocera]

On Tue, 2010-10-19 at 01:44 +0200, Ryan Lortie wrote:
> Hi,
> 
> While I wasn't looking, Cody Russell gained access to my laptop and
> pushed the GApplication branch to glib master.  He admits to it, even:
> 
> http://twitter.com/bratschegnome/status/27779385082
> 
> Shortly afterward he redeemed himself (and fixed the GTK build) by
> pushing the new GtkApplication code.
> 
> The upshot, though, is probably that quite some application that were
> making use of the old GApplication have stopped working.
> 
> My recommendation is to check out this small example application that
> I've included in Gtk:
> 
> http://git.gnome.org/browse/gtk
> +/tree/gtk/tests/gtk-example-application.c
> 
> The actions stuff is not implemented in the new GApplication yet, but it
> will be coming soon (probably this week, since we're all at the hackfest
> together).  I don't think anybody is currently heavily depending on that
> for functionality at this point...

Huh, some of us did:
http://git.gnome.org/browse/totem/tree/src/totem-options.c#n93
http://git.gnome.org/browse/totem/tree/src/totem-options.c#n144
http://git.gnome.org/browse/totem/tree/src/totem-options.c#n174

You broke Totem :)

Cheers

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

Re: G/tkApplication

[Maciej Piechotka]

On Tue, 2010-10-19 at 10:01 +0100, Richard Hughes wrote:
> On 19 October 2010 00:44, Ryan Lortie  wrote:
> > The upshot, though, is probably that quite some application that were
> > making use of the old GApplication have stopped working.
> 
> So... what versions of gtk+ and glib should GNOME 2.91.1 tarballs be
> targeted against?
> 
> Can I just skip 2.91.1 tarballs and just ask people to compile
> everything from git master?
> 

Please don't do that (I'm asking as user). I stopped using 2.9x GNOME
because I was tired of trying to check what revision of which packages
works with what revision of gtk+/gobject-introspection. 

"Compile everything from git" may require users to downgrade packages
from time to time as, for example, gedit requires gtk+ 2.90.6 while
webkit requires <2.90.6 (historical example).

Unless there will be some 'stable' releases of GNOME 2.9x (i.e. those
which at least build against each other & work for some wide definition
of work) I am certain that I won't bother with trying it - and I would
be surprised if many other would.

> Richard.

Regards


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: G/tkApplication

[Richard Hughes]

On 19 October 2010 00:44, Ryan Lortie  wrote:
> The upshot, though, is probably that quite some application that were
> making use of the old GApplication have stopped working.

So... what versions of gtk+ and glib should GNOME 2.91.1 tarballs be
targeted against?

Can I just skip 2.91.1 tarballs and just ask people to compile
everything from git master?

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