Re: [GitLab] Projects moved and 'tips of the week'

[Robert Ancell]

On Thu, 11 Jan 2018 at 06:53 Carlos Soriano  wrote:

>
> - *Set up basic CI* with build, tests and coverage (gcov) for your meson
> C project: Take a look at Nautilus
>  for
> a simple example.
>

You can also easily set up CI to build on multiple OSs (e.g. Ubuntu and
Fedora). See the simple-scan CI configuration
 for
example.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.25.90 will probably be delayed

[Robert Ancell]

Can you attach your two versions of the .vapi? On Ubuntu 17.10 they are
almost identical and would compile against either one.

On Thu, 10 Aug 2017 at 10:06  wrote:

> On Tue, Aug 8, 2017 at 10:45 PM, mcatanz...@gnome.org wrote:
> > OK, I'm done sending emails. If you don't have a mail from me, then
> > your module is probably fine.
> >
> > Michael
>
> Another update. Thanks to lots of help from lots of people, I'm down to
> just three known build failures. (There might be more hidden behind
> modules I failed to build last night, but probably not many.) Two are
> easy and just need new tarballs. There is only one real problem right
> now: simple-scan. Here is the build error:
>
>
> ../../../../releases/gnome-apps-3.25.90/simple-scan-3.25.90/src/app-window.vala:1441.95-1441.100:
> error: The name `code' does not exist in the context of `Pk.Error'
>result_text = _("Failed to install drivers
> (error code %d).").printf (e.code);
>
> ^^
> Compilation failed: 1 error(s), 0 warning(s)
> ninja: build stopped: subcommand failed.
>
> The problem seems to be that in GNOME we have two different, competing
> packagekit-glib2.vapi files: one installed by PackageKit and one
> installed by vala. The one installed by vala has Error.code, but the
> one installed by PackageKit seems to take precedence, and it does not
> have Error.code. The two sets of bindings are really
> significantly/worryingly different. I'm really not sure what to make of
> this.
>
> Since this might indicate a major issue somewhere in either the
> gobject-introspection or vala stacks, I don't think we should proceed
> until simple-scan is buildable.
>
> Michael
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GCalctool renamed to GNOME Calculator

[Robert Ancell]

Hi,

I have renamed the GCalctool project to GNOME Calculator with the first
release being 3.7.1 (we can now follow the GNOME numbering). The git module
is now gnome-calculator (please now update translations/documentation
there) and bugzilla will soon be moved to gnome-calculator.

Thanks,
--Robert
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games split

[Robert Ancell]

On 17 October 2012 21:08, Allan Day allanp...@gmail.com wrote:

 Robert Ancell robert.anc...@gmail.com wrote:and thus easiest
  So, I think we should decide based on the following:
  - A range of games that cover easy games that children can play to
  difficult puzzles suitable for adults.
  - Games that are modern and fun
  - A small enough set that can be effectively maintained and improved
  to keep standard high
  - A small enough set that can be effectively browsed from the shell

 When I looked at this last, I came up with the shortlist of aisleriot,
 sudoku, iagno and tetravex. These seem to cover the categories you
 describe above. They also have concepts that are clear and easy to
 pick up. While people might like mines, I don't think it makes a good
 default game: it seems rather archaic.


 I guess this needs to be finished - I say since no opposition then just
let the design team (i.e. Allan) here decide. I would suggest reconsidering
mahjongg, imo it's one of the nicer looking games and it plays the best on
touch devices. Thomas - do you want to update jhbuild?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Fwd: GNOME Games split

[Robert Ancell]

-- Forwarded message --
From: Robert Ancell robert.anc...@gmail.com
Date: 9 October 2012 22:03
Subject: GNOME Games split
To: GNOME Games List games-l...@gnome.org, GNOME Documentation
gnome-doc-l...@gnome.org, gnome-i...@gnome.org


Hi all,

The GNOME Games module split is now complete; this means that the
gnome-games git repository is obsolete and shouldn't be committed to.
There will be individual releases for each of the games from 3.7
onwards.

The new git repositories are

glchess - gnome-chess*
glines- five-or-more
gnect   - four-in-a-row
gnibbles- gnome-nibbles
gnobots2- gnome-robots
gnome-sudoku- gnome-sudoku
gnomine - gnome-mines
gnotravex   - gnome-tetravex
gnotski - gnome-klotski
gtali   - tali
iagno   - iagno
lightsoff - lightsoff
mahjongg- gnome-mahjongg
quadrapassel- quadrapassel
swell-foop  - swell-foop

Bugs are still tracked in the gnome-games module for now, but they
will be migrated to new bugzilla products once they are ready.

Aside from that it's business as usual!

--Robert

*gnome-chess is not pushed yet as there is an archived module using
this name. https://bugzilla.gnome.org/show_bug.cgi?id=685539
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Splitting GNOME Games and modules names (gnome-chess etc)

[Robert Ancell]

Hi,

For 2.8 we are now in a state to split GNOME Games into separate modules.

Here are the current binary names of the games and the proposed module
names for them:

glchess - gnome-chess
glines- five-or-more
gnect   - four-in-a-row
gnibbles- nibbles
gnobots2- gnome-robots
gnome-sudoku- gnome-sudoku
gnomine - gnome-mines
gnotravex   - gnome-tetravex
gnotski - gnome-klotski
gtali   - tali
iagno   - iagno
lightsoff - lightsoff
mahjongg- gnome-mahjongg
quadrapassel- quadrapassel
swell-foop  - swell-foop

For generic names I've prefixed gnome- so we're unlikely to collide
with other projects. In the game the gnome- prefix will not be visible
in the UI, i.e. the application will just be called Chess, Sudoku
etc.
I'm taking this opportunity to drop all the sucky g- gno- prefixes. :)

Questions:

1. gnome-chess was the name of an old GNOME module. Does anyone have
any opposition to me using it?
2. Anyone know if any of these collide with anything existing?
3. Any advice on how to transfer the code to the new modules? Do we
lose all the git history?

Thanks,
--Robert
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Simple Scan tarballs

[Robert Ancell]

https://bugzilla.gnome.org/show_bug.cgi?id=672972

On 27 March 2012 10:28, Olav Vitters o...@vitters.nl wrote:
 On Tue, Mar 27, 2012 at 10:20:45AM +1100, Robert Ancell wrote:
 The GNOME FTP module scripts have never really seemed to be happy with
 simple-scan releases being uploaded without there being a bugzilla
 account for it, and now it doesn't seem to work at all.  So I've
 decided to upload the released directly to Launchpad now.  The
 downside of this is there aren't any automatic FTP announcements of
 released in GNOME.

 Please file a bug on GNOME Bugzilla against sysadmin product (or maybe
 sysadmins).

 The Bugzilla stuff is crappy (+difficult to fix; RHEL5 problem), but optional.

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

Simple Scan tarballs

[Robert Ancell]

The GNOME FTP module scripts have never really seemed to be happy with
simple-scan releases being uploaded without there being a bugzilla
account for it, and now it doesn't seem to work at all.  So I've
decided to upload the released directly to Launchpad now.  The
downside of this is there aren't any automatic FTP announcements of
released in GNOME.

The 3.4 series is here:
https://launchpad.net/simple-scan/3.4

And this is the latest release:
https://launchpad.net/simple-scan/3.4/3.4.0/+download/simple-scan-3.4.0.tar.gz

Simple Scan continues to follow the GNOME release schedule.

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

Re: On the Interaction with the design team

[Robert Ancell]

On 3 June 2011 19:55, Dave Neary dne...@gnome.org wrote:
 Hi,

 On 06/02/11 02:02, Robert Ancell wrote:

 A huge +1 on this.  IRC is much more productive, but it's crucial that
 it's logged for people who can't attend.  (I'm always hitting this
 problem in GNOME trying to work out what happened while I was sleeping
 in Australia).
 This works really well in Ubuntu where everything is automatically
 logged: http://irclogs.ubuntu.com/

 Out of interest, how long after an IRC conversation that concerns you do you
 typically find out about it? Do you read the entire IRC log of the relevant
 channels every morning?

 How often do you actually go looking in the logs?

It's either something that happened in the last day or two, or
something much later that I want to check for accuracy.

I don't read entire logs, though I do review meetings that occur in
the logs from time to time.  I'd say I look up something in the Ubuntu
logs a few times per month.

 I really don't think IRC logs are a good way of communicating anything. It's
 better than unlogged, but really only marginally.

Sure, and they shouldn't be used as a replacement for communicating
any formal information.

What I miss in GNOME is not being able to read what happened in a
meeting, or reading up the context of a decision.  People copy
snippets from IRC conversations into bug reports, and I want to read
more about the decisions that were made.  Also being out of sync with
a lot of people means I can't just ask someone a question the next
day, and it would be nice to just be able to check it in the logs.
You potentially miss out a lot if your not in a common timezone, or a
part time contributor (e.g. the design process).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[Robert Ancell]

On 2 June 2011 06:10, Colin Walters walt...@verbum.org wrote:
 Hi Johannes,

 On Wed, Jun 1, 2011 at 12:38 PM, Johannes Schmid j...@jsschmid.de wrote:

 I think you miss the original point of the discussion: Even people that
 would want to join the discussion have a hard time doing it if
 everything is discussion on IRC (at a certain time) only.

 I would really love to see someone set up official logging of GNOME
 IRC, like MeetBot or whatever.  Several people run private loggers,
 but we'd just need to make clear to participants that it is being
 publicly logged.

A huge +1 on this.  IRC is much more productive, but it's crucial that
it's logged for people who can't attend.  (I'm always hitting this
problem in GNOME trying to work out what happened while I was sleeping
in Australia).
This works really well in Ubuntu where everything is automatically
logged: http://irclogs.ubuntu.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 18 May 2011 20:06, Fernando Herrera fherr...@onirica.com wrote:
 On Wed, May 18, 2011 at 4:03 AM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 But I think the point you are
 making that I was missing is there is nothing that starts
 at-spi-registryd?  So even though the greeter has ATK support, it will
 not do anything?

 That's right, but no only the registry. You also need to start the AT
 applications needed by the user, like the screen reader, on screen
 keyboard, sticky keys, etc...

 Just to make it clear, this is a common use case:
 - Bob is a blind users who has installed XX distrbution and configured
 to use GNOME in English with an screen reader and the voice he likes.
 - After turning on the computer the login manager starts
 - The login manager starts the accesibility registry., the greater and
 screen reader, so Bob can navigate the greater UI and type his name
 and password.

 Hope this helps to get a clear picture.

Yes, thanks Fernando!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 17 May 2011 11:37, Fernando Herrera fherr...@onirica.com wrote:
 Hi,

 On Tue, May 17, 2011 at 7:01 AM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 So, how? I mean, currently I don't see anycode on lighDM for this. Are
 you going to solve that at the distro level using some kind of script
 that would start the greeter and then the required AT?

 This logic would need to be in the greeter - the LightDM daemon does
 not have any requirement to have a11y support that I can tell of.  The
 current example greeters have the a11y support their toolkits have
 (not tested yet).

 Well, I think that LightDM requirements are not the point here (and
 the reality is that LightDM current implementation/code is not
 accessible). The point are the requirements that any application to be
 included in GNOME:
 [...]
 Accessibility: Accessibility is a core value of GNOME. The app is
 compliant with a11y documentation to as great an extent as possible,
 and the maintainers have made good faith efforts to fix all a11y bugs
 filed in a timely manner by the a11y team. Please take the time to do
 a 15 minute accessibility smoke test on your GUI if your module
 includes a GUI.
 [...]

 I know that we broke this rule for GNOME 3 with gnome-shell, but that
 was a very special situation and the plan is to fix it for GNOME 3.2.

 Also please remember that the login manager is a very special
 application that enables the user to start using the computer and if
 it is not accessible, the whole desktop won't be.

 Thanks!

 Salu2


This is a question that keeps cropping up, and I think I haven't been
answering/understanding the question correctly.

Firstly, LightDM does not have provide a GUI, so does not have any
a11y requirements that I can tell.  The greeter, which is basically an
X application (or a group of X applications if running a session) is
the part that would need a11y support.  This is much the same as
PolicyKit, where the core PolicyKit does not require a11y, but
PolicyKit-GNOME (or as implemented in GNOME Shell now) does.

If we look at the LightDM repository there is an example GTK greeter.
This uses GTK, so it has ATK support.  But I think the point you are
making that I was missing is there is nothing that starts
at-spi-registryd?  So even though the greeter has ATK support, it will
not do anything?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 13 May 2011 21:33, Ray Strode halfl...@gmail.com wrote:
 Hi,

 On Fri, May 13, 2011 at 1:06 PM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 Note that LightDM is not lighter in features, but in architecture.
 And a different focus, right? GDM is firmly a GNOME project, designed
 to integrate and work well with GNOME.  LightDM is designed with the
 idea of being more generic right?

 More generic in the parts that are common.  In the parts that are
 GNOME specific, as differentiated as is required.
 But you said someone will need to volunteer to do the GNOME
 integration part, right?

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

Re: New module proposal: LightDM

[Robert Ancell]

On 14 May 2011 00:19, Matthias Clasen matthias.cla...@gmail.com wrote:
 On Fri, May 13, 2011 at 12:55 PM, Robert Ancell robert.anc...@gmail.com 
 wrote:


 I was not going to propose this project because I am sick of this sort
 of unprofessional response, especially from leaders in the community.
 It was the insistence of other leaders in the GNOME community that I
 did end up proposing and the continual complaints from users,
 sysadmins, customers, designers, and programmers about the login
 experience.

 So, you consider it an unprofessional response if we are not falling
 over our feet in adopting a from-scratch rewrite of a core component
 that has not even been field-tested in any release yet ? Compare to
 the approach that Canonical takes to new things like, say GNOME3.. I
 think you will see some similarities.

Not at all.  All I want is a fair review, based on good technical
information and not being name-called or judged on assumptions about
my motivations.  Not being field-tested is a completely fair
criticism, and something I can take away and reuse in a proposal for
GNOME 3.4.

As both a Canonical employee and Ubuntu developer I can tell you we
constantly review all available free software for inclusion.  While we
do not always agree on every point we agree on a lot more than we
disagree.  I'm happy to continue to discuss this on another thread or
privately if you want to.

 Anyway, you are already pissed off, so probably best to stop...

My frustrations have certainly boiled over, but I will now resolve
those through the appropriate channels.  Apologies for the anger.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 14 May 2011 14:38, Fernando Herrera fherr...@onirica.com wrote:
 Wops, I moved the conversation offlist. Getting back to d-d-l.

 On Fri, May 13, 2011 at 4:06 PM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 On 13 May 2011 15:56, Fernando Herrera fherr...@onirica.com wrote:
 What about starting AT applications like orca to use them to interact with
 the greater?

 Yes, that is probably the solution we will use in Ubuntu/Unity.

 So, how? I mean, currently I don't see anycode on lighDM for this. Are
 you going to solve that at the distro level using some kind of script
 that would start the greeter and then the required AT?

This logic would need to be in the greeter - the LightDM daemon does
not have any requirement to have a11y support that I can tell of.  The
current example greeters have the a11y support their toolkits have
(not tested yet).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 14 May 2011 00:45, Florian Müllner fmuell...@gnome.org wrote:
 On Fri, 2011-05-13 at 14:59 +0200, Robert Ancell wrote:
 Why replace GDM?

 - LightDM is a cross-platform solution.

 Will KDE replace kdm with LightDM or drop its non-greeter code in favor
 of LightDM? Are there any interesting discussions in the other camp
 that you can point us to?

I unfortunately have not focused on the KDE community for default
usage yet, as this is not a community I am familiar enough with yet.
The Kubuntu developers are considering if it is appropriate for them
to use LightDM and they have plans to discuss this with upstream.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

On 13 May 2011 15:19, Miguel de Icaza mig...@novell.com wrote:
 Hello,

 Why replace GDM?

 What user-facing problem does this solve?

The main advantage I see to GNOME is to reduce the amount of GNOME
specific code that needs to be maintained.  In terms of users, the
ability to implement a greeter design is the useful aspect.

 In general, GDM code is ugly not because of what it does, but to
 prevent a wide range of security attacks that are attempted against
 login managers.

 Writing a login manager is not difficult, hardening one is.

 May I suggest that before this is considered, a security team performs
 an audit of all the security exploits that have been attempted against
 GDM, XDM and KDM and ensure that none of those can be exploited with
 the current code base.

Absolutely

 Additionally, we should compare the bug list from GDM and make sure
 that features that were implemented are not dropped, and that bugs
 that were fixed continued to be fixed here.   This just be just to
 prevent another case of CADT [1].

Also agree.


 Miguel

 [1] http://www.jwz.org/doc/cadt.html



 - LightDM is a cross-platform solution.  Ubuntu is planning to switch
 to it this cycle, and other distributions have expressed interest in
 the project.  By sharing this piece of infrastructure GNOME can spend
 more time working on important GNOME components.  LightDM is aligned
 with freedesktop.org.

 - I am confident that the LightDM architecture is simpler than GDM.
 Some indicators of this:
  - Smaller code size
  - Well defined interface between greeter and session
  - Less dependencies
  - Less internal interfaces
  Architecture can be a personal opinion, and I encourage those with
 programming experience to look at the code and decide for themselves.
 Note that LightDM is not lighter in features, but in architecture.

 - By having a well defined interface between the greeter and daemon,
 it is significantly easier to develop a greeter without knowledge of
 how display management works.  This is useful as the skillset and
 motivations of these two sets of developers are different.

 - LightDM is a platform for future work and is investigating the use
 of new technologies like Wayland.

 The details:
 Purpose:  Cross-desktop display manager
 Target: desktop
 Dependencies: libglib, libpam, libxdmcp, libxcb, libxklavier,
 gobject-introspection, libgtk+
 Resource Usage: Launchpad for source control and bug tracking [1],
 tarballs in public ftp [3] (in process of moving to freedesktop.org)
 Adoption: Accepted for use in Ubuntu 11.10, interest from other distributions
 GNOME-ness: Display manager is cross-desktop, example GTK+ greeter is
 fully GNOME compliant.  I would recommend this module is maintained in
 the GNOME servers to get all the build and translation support.
 3.0 readiness: GTK greeter currently using GTK2, but all other code
 uses latest GNOME standards.
 License: GPL3

 [1] https://launchpad.net/lightdm
 [2] 
 https://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00226.html
 [3] http://people.ubuntu.com/~robert-ancell/lightdm/releases/
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list


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

Re: New module proposal: LightDM

[Robert Ancell]

On 13 May 2011 18:32, Ray Strode halfl...@gmail.com wrote:
 Hi,

 (speaking again as one of the three GDM maintainers)

 On Fri, May 13, 2011 at 8:59 AM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 Why replace GDM?

 - LightDM is a cross-platform solution.
 What platforms does LightDM support that GDM doesn't?  Are they
 platforms GNOME is targetting?  Not sure this is necessarily a win
 without knowing more details.

The value to GNOME is not that it can run on different platforms, the
value is that the component can be shared.

 Ubuntu is planning to switch to it this cycle,
 Sure, and I can see how that decision may potentially make sense for
 Canonical (you would be able to offer in-house expertise, better
 control over unity integration etc etc.)

And we would have loved to use GDM, it certainly wasn't through lack
of trying.  For Ubuntu the Unity aspects will be in the Unity greeter,
but the core LightDM daemon/libraries will not contain anything Unity
specific.

  By sharing this piece of infrastructure GNOME can spend
 more time working on important GNOME components.
 So you're saying, we could stop working on GDM, Brian, McCann and I
 could leave the login screen to you to handle and we could use the
 extra time we got to work on other parts of GNOME?  There's no
 question that we're all busy, for sure, but let's look at the big
 things (modulo small patch review, security errata, etc, that would
 exist in both projects) needed for GDM:

 1) Landing the multiple simultaneous pam conversations branch of GDM
 so you get sane behavior in the presence of smartcards, fingerprint
 readers, etc.  This lets you swipe your finger, insert your smart
 card, or whatever while sitting at a enter password prompt.
 2) Giving GDM a more of a GNOME 3 look and feel (as per the mockups
 you already mentioned elsewhere in the thread)
 3) Better support starting a login screen dynamically a keyboard,
 mouse, and display show up (multi-seat).  Also, see the work Lennart
 and Kay are discussing lower in the stack to help facilitate some of
 this.
 4) Figuring out how GDM,  screen locking, and the shell all fit together

 I don't think LightDM will help us with any of these 4, will it?

These are all valid features and I completely support making a list of
requirements for GNOME for LightDM to be even considered.  I am
absolutely fine for this proposal to be rejected on grounds like this.

 Note that LightDM is not lighter in features, but in architecture.
 And a different focus, right? GDM is firmly a GNOME project, designed
 to integrate and work well with GNOME.  LightDM is designed with the
 idea of being more generic right?

More generic in the parts that are common.  In the parts that are
GNOME specific, as differentiated as is required.

 - By having a well defined interface between the greeter and daemon,
 it is significantly easier to develop a greeter without knowledge of
 how display management works.  This is useful as the skillset and
 motivations of these two sets of developers are different.
 Not sure how much of a selling point multiple greeters is, but GDM's
 architecture allows for it.

 Dr. Mo even did one apparently:
 http://doctormo.org/2011/04/12/how-to-make-a-gnome-login-screen-in-python/

Yes, I did congratulate him on that! :)

 Anyway, I'm obviously of the opinion we should stick with GDM.  There
 just doesn't seem to be a good reason to switch.

I'll keep trying to convince you, thanks for the feedback Ray. :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[Robert Ancell]

On 12 May 2011 23:42, Luca Ferretti lferr...@gnome.org wrote:
 Il giorno gio, 12/05/2011 alle 20.45 +0100, Sergey Udaltsov ha scritto:

 GNOME is not an OS. GNOME is not a distribution. GNOME is a core
 desktop (desktop building toolkit, if you like) that is used by
 distributions - it is them who define the _final_ user experience. Do
 we all agree that GNOME should be distribution-friendly, that GNOME
 should trust distributions, make their life reasonably comfortable?

 I totally agree, IMHO GNOME is a base to allow distributors, vendors and
 third parts to build up and extend their own user experience and
 services and fight on free market. No competition means stagnation.

 But it seems by now we are a small minority :-|

Or are we a silent majority?  It seems we don't have enough
information to say either way.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fix gsettings path to use /org/gnome instead /apps

[Robert Ancell]

Two questions:

1) Where is it defined what format the path is supposed to be in?
2) What about migration of settings from the old path to the new path?

--Robert

On 25 March 2011 09:41, Luca Ferretti lferr...@gnome.org wrote:
 Flash news from release team to our all brave developers.

 A member of release team known as *cough*Luca Ferretti*cough* was sure
 gsettings PATHs and gsettings IDs were the same, so he was also sure all
 GNOME 3 core apps were using the proper path. So he never sent any
 notice or filed bug report...

 But we don't want to blame his errors, we want to have a fine tuned
 GNOME 3 Desktop. A quick grep[1] shows about 15 basic modules using the
 wrong PATH. Patches are available here[2][3].

 No string changes, no code changes, no UI changes (except paths showed
 in dconf-editor, but this is totally undocumented by now), and hard code
 freeze exception yet pre-approved.

 If you have no time to commit, I'll be glad to help you, just ask on irc
 (elle.uca) or reply here.

 Next step: do the same on non-core modules, but I suppose we can work on
 it during 3.2 timeline.

 Cheers, Luca

 [1] http://paste.ubuntu.com/584321/
 [2] http://people.gnome.org/~lferrett/patch/
 [3] actually it misses a patch for org.gnome.packagekit.gschema.xml





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

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

Re: GSettings best practice

[Robert Ancell]

+1 for just picking a policy.  I suspect no-one really cares what the
policy is, as long as there is one.  Please pick one and make it
official by documenting it somewhere prominent!

On 8 November 2010 02:57, Ryan Lortie de...@desrt.ca wrote:
 Hi everyone,

 We were sitting around at the Boston summit today (me, vuntz, tedg, and
 pbor via IRC) noticing that we have a mix of people using /apps/gedit/
 sort of paths and /org/gnome/evince/ sort of paths in GSettings.

 We all prefer /org/gnome/evince/ type of paths.

 Cheers

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

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

Re: New module proposal: LightDM

[Robert Ancell]

Thanks for the feedback Ray,

I hadn't considered if GNOME recommend more than one display manager?
I don't know.  I'm trying to align LightDM as a freedesktop.org
project closely related to the X server (and thus an external
dependency) with a GNOME greeter developed as a full GNOME project.

For some background, LightDM came from a weekend project after trying
to document the greeter-daemon interface and I was trying to better
understand the interactions in GDM.

While I appreciate the use of a full session for the greeter has it's
advantages, I'm not sure they're all necessary for the limited GUI
required in a greeter.  It really comes down to flexibility - I think
any capable application developer should be able to develop a greeter
(with a full session if required) without needing detailed knowledge
of how the display manager works.  I had been trying to get this
interface into GDM, but I'd come to the conclusion that the
architecture of GDM is overly complex and that holds back innovation.
The weekend project confirmed to me that we can have all the same
features without the complexity.

I am talking with other projects and trying to get people working
together.  I'd like to see the fragmentation in display managers
reduce so we can look at the daemon as the boring reliable bit and
have people go wild designing new interfaces!


On 22 October 2010 16:17, Ray Strode halfl...@gmail.com wrote:
 Hi,

 (speaking as one of the 3 maintainers of GDM)

 On Thu, Oct 21, 2010 at 12:02 AM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 - The GDM greeter is slow due to it loading the GNOME session, the
 example GTK+ LightDM greeter is very lightweight (so is comparable to
 the speed of the old GDM and newer display managers like LXDM).
 Using GNOME session / g-s-d /etc  is one of GDMs main features.  The
 point is for there to be consistent experience on the login screen and
 in the session.
 If GDM is too slow because of GNOME session then GNOME session needs
 to be fixed, otherwise login after GDM will be too slow too.  Anyway,
 if gnome-session is slow on your machine we should start by profiling
 it and figuring out why.

 - The GDM greeter has very limited themeing capabilities.  A
 contributor to LightDM (PCMan) was able to quickly write a new greeter
 that used GtkBuilder and provided comparable themeing support to the
 old GDM.
 GDM uses the standard theming mechanism as the rest of GNOME.  This a
 good thing.

 Making GDM use GNOME components and integrate with GNOME is not a bad
 thing. It used to not do that and was explicitly changed...

 Of course, things will need to be rethought about in a post- GNOME 3
 world (use mutter / clutter?)

 - While it is technically possible to write an alternate greeter for
 GDM, in practise it is too difficult.  LightDM has been designed from
 the start to make writing a greeter no harder than a standard X
 application.
 Granted, the interface between greeter and daemon isn't
 as clean as it could be.  Still,

 1) it's obviously not too difficult, or there couldn't be one
 functioning greeter
 2) When writing a new greeter becomes a priority to someone, the
 interface is completely changeable. It's a private interface so it can
 be changed in any way that's needed.

 - All X server users have pretty much the same requirements beyond the
 login GUI.  By using LightDM the development effort of maintaining the
 display manager can be shared between projects (GNOME, KDE, LXDE,
 XFCE).
 So you're not proposing LightDM to become part of GNOME, you're just
 proposing GDM get dropped and LightDM become an external dependency?

 Have you talked to the other projects about this?  We had some
 discussions some time back with Oswald (KDE developer) about
 standardizing on one display manager a few years ago:

 http://mail.gnome.org/archives/gdm-list/2007-October/msg00013.html
 (added him to cc list)

 Anyway, I'm obviously in favor of keeping GDM in GNOME.  I admit it
 has some baggage (some of it removed and added back later by popular
 demand), but overall GDM is in really good shape as a project.. FWIW,
 your various patches over the years have been a part of getting GDM to
 where it is.

 --Ray

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

Re: New module proposal: LightDM

[Robert Ancell]

 I also want to say something slightly off-topic regarding impulse to
 change.  A lot of users hate when things they use get changed.  It
 screws up their workflows, etc, and so many changes are controversial.
  Often there's a gut reaction can you provide a way for me get things
 back to the old way from the new way.  I'm sure a lot of people on
 this list know what I'm talking about. For some reason, that same
 impulse doesn't seem as strong when users change to different
 functionally similar apps.  What I mean is, it's not okay if App A
 changes the way something works or removes a feature, but if App B
 never provided that feature in the first place then the user may
 switch from App A to App B and be quite happy (even though App B
 completely changes their workflows!)  I've never understood this, but
 I've seen it happen a lot (not talking about LightDM and GDM in
 particular here, just an off topic side note)

My guess on this is if App B significantly improves their experience
then users don't worry too much about features that have gone.  App
A+1 is like an App B but without the step change in improvement and so
users are more critical of removals.  Perhaps the only solution as a
module maintainer is to only allow removals with major improvements
(almost impossible if you do a major refactoring).  I certainly hit
this problem in gcalctool...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

LightDM does not require copyright assignment and is not developed as
a Canonical project.

On 21 October 2010 20:11, Christian Persch c...@gnome.org wrote:
 Hi;

 LightDM is not currently listed on
 http://www.canonical.com/contributors ; can you confirm that it does
 not require, nor will ever in future require, copyright assignment?

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

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

Re: New module proposal: LightDM

[Robert Ancell]

Yes, I have seen those screens, have not discussed those with them
yet, but they do look great!

To implement that would require writing a greeter that uses LightDM.
That could either be done by extending the GTK+ greeter that comes
with LightDM or writing a new greeter (e.g. using clutter etc) that
uses the LightDM API.  From the screenshots I would think that LightDM
provides enough information to work (but will ask what their
requirements are).

On 21 October 2010 20:35, Frederic Peters fpet...@gnome.org wrote:
 Robert Ancell wrote:

 I'm proposing LightDM [1] as a replacement for GDM.  However, due to
 the young age of the project and the importance in the desktop stack I
 don't think it's ready for immediate adoption.  I'd like to go through
 the proposal process, encourage feedback, encourage developers to try
 it during 3.0 and re-propose it for 3.2.

 Do you know about current login screen ideas (as exemplified in [1]),
 did you already discuss those with the design team, what do you think
 about them... in short, how do you think LightDM fits GNOME 3 as it's
 being planned?

  [1] http://live.gnome.org/GnomeShell/Design/Whiteboards/LoginScreen


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

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

Re: New module proposal: LightDM

[Robert Ancell]

On 21 October 2010 21:17, Sam Spilsbury smspil...@gmail.com wrote:
 Just a few things to note:
 - It seems to spawn about 4 or 5 server instances before it actually gets to
 your session. Is this intended?

No, the lightdm server should only have one instance.

 - LightDM doesn't appear to pull in your gtkrc or anything from
 gnome-settings-daemon (eg a11y properties and the like). Will this be
 resolved?

In the greeter or the user session?

Please send me more information on these problems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Robert Ancell]

  - LightDM doesn't appear to pull in your gtkrc or anything from
  gnome-settings-daemon (eg a11y properties and the like). Will this be
  resolved?

 In the greeter or the user session?

 The greeter should be ally compliant(TM).  Is it?

The greeter is a GTK+ application using standard widgets so it has all
the usual a11y support.  BUT, it is not running a session so you
cannot launch orca and anything else that would run in a standard
GNOME session.  It may need to launch additional services to provide
all the required features.

The greeter currently provides the following a11y features:
- Ability to switch to a large font size
- Ability to enable high contrast theme

Yes, the greeter would have to a11y compliant, and the current greeter
may not be sufficient.  Note that it would seem quite appropriate that
a new greeter would be developed for GNOME that better fitted in with
GNOME shell technology - the current greeter is more of a proof of
concept.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Robert Ancell]

Is soup required now that we have GIO?

On 8 March 2010 08:16, Shaun McCance sha...@gnome.org wrote:
 Hi folks,

 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:

 http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

 I've tried starting this discussion before, but haven't
 gotten a lot of response.  So rather than ask, I'm going
 to propose a list of technologies and see if there are
 any objections.

 I'm taking the big tent approach.  If we're using it,
 and it's not something we consider to be a system library,
 then it's in.  I don't care if it's in the platform, the
 desktop, or the external dependencies.  I want to present
 third-party developers with the most complete development
 platform possible.

 I also want to focus on developer tools.  They should be
 featured heavily when we talk about how to develop for
 Gnome.

 Enough yakking.  Libraries I'm going to push:

 * GTK+
 * GLib (+ GObject, GIO, GSettings)
 * Pango
 * Cairo
 * ATK
 * AT-SPI
 * Clutter
 * PackageKit
 * Tracker
 * Telepathy
 * Evolution Data Server
 * Gnome Keyring
 * GStreamer
 * WebKitGTK+
 * Soup
 * Avahi
 * DBus
 * DeviceKit-disks
 * DeviceKit-power
 * Canberra
 * PolicyKit
 * PulseAudio

 I'm going to focus on the following programming languages:

 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 Developer tools I'll be pushing:

 * Anjuta
 * Devhelp
 * Glade
 * Accerciser
 * Nemiver

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

 After the Overview content is planned, I'll begin work
 on planning the introductions.  These are the going to
 be the first thing a lot of new developers see, so we
 have to make them rock.

 Happy hacking.

 --
 Shaun McCance
 http://syllogist.net/

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

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

Re: New module proposal: Simple Scan

[Robert Ancell]

I have a simple-scan lightning talk I was going to give at LCA2010.
I'm not sure if there's enough to say about simple-scan to do a full
talk!

Colour management is the #1 feature for post 1.0:
https://bugs.launchpad.net/simple-scan/+bug/498029

I don't know a lot about it but I will participate in a mini-conference.

--Robert

On 20 February 2010 02:57, Richard Hughes hughsi...@gmail.com wrote:
 On 19 February 2010 00:01, Robert Ancell robert.anc...@gmail.com wrote:
 I'd like to propose Simple Scan for inclusion in GNOME 3.0

 I would love to talk over color management support in simple scan. Are
 you going to give a talk at GUADEC? I can arrange a mini-conference
 call for interested parties if you want.

 Richard

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

New module proposal: Simple Scan

[Robert Ancell]

I'd like to propose Simple Scan for inclusion in GNOME 3.0

Website: https://launchpad.net/simple-scan
Tarballs: http://people.ubuntu.com/~robert-ancell/simple-scan/

Purpose: Simple scanning application, suitable for single-click scanning
Target: Desktop
Dependencies: libsane (http://www.sane-project.org/, scanner device
drivers), udev (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html,
detect scanners being connected and disconnected)
Resource usage: Currently Launchpad, will migrate to GNOME
Adoption: Used in Ubuntu, Debian
GNOME-ness, community: Follows all GNOME standards (GTK+, GtkBuilder,
HIG, Mallard documentation, fully translatable)
3.0 readiness: All up-to-date
License: GPL 3.0
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GCalctool branched for 2.30

[Robert Ancell]

GCalctool head is now for GNOME 2.30/3.0 and the 2.28 stable branch is
called gnome-2-28
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GCalctool 2.24 branched

[Robert Ancell]

Apologies for the lack of announcement; this was my first branch made
for GNOME...

GCalctool has (was) branched for GNOME 2.24!

2.24 stable bugfixes are occuring on the branch:
http://svn.gnome.org/svn/gcalctool/branches/gnome-2-24/

The focus for 2.24 is fixing bugs and performance problems in calculations:
http://bugzilla.gnome.org/buglist.cgi?product=gcalctoolbug_status=NEWbug_status=REOPENEDbug_status=ASSIGNEDbug_status=UNCONFIRMEDtarget_milestone=2.24.0

2.25 development is occurring on the head:
http://svn.gnome.org/svn/gcalctool/trunk/gcalctool/

The foci for 2.25 are:
- Continuation in simplifying and documenting the code base
- Improving the user interface (making financial functions have
dialogs, adding colours to the UI, using unicode characters in
display, e.g. unicode multiply symbol)
- Adding new functions (more inverse functions, programming mode,
conversion functions)
http://bugzilla.gnome.org/buglist.cgi?product=gcalctoolbug_status=NEWbug_status=REOPENEDbug_status=ASSIGNEDbug_status=UNCONFIRMEDtarget_milestone=2.26.0

Happy hacking!
--Robert

2008/9/29 Claude Paroz [EMAIL PROTECTED]:
 Le dimanche 28 septembre 2008 à 04:40 +, GNOME Status Pages a
 écrit :
 This is an automatic notification from status generation scripts on:
 http://l10n.gnome.org/.

 There have been following string additions to module 'gcalctool.HEAD':

 + Calculator - Programming
 + Calculator [%s] - Programming
 + Programming
 + _Programming

 Gcalctool branched for GNOME 2.24 some days ago, but I don't remember
 having seen any notice on gnome-i18n.
 Robert, please don't forget to announce branching as of
 http://live.gnome.org/MaintainersCorner

 Claude


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