Re: Proposal to deploy GitLab on gnome.org

[Rodrigo Moya]

Hi

> On 17 May 2017, at 12:33, Sébastien Wilmet  wrote:
> 
> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
>> I don't share your optimism about gitlab bug tracking, nor do I share
>> in the mentioned frustration with bugzilla. 
> 
> Me too, I like bugzilla (but not for doing code reviews).
> 
> What would be the pain points if GitLab is used only for git and code
> reviews, and we keep bugzilla for the bug tracker? Have you considered
> that option?
> 
> We would loose automatic links between bug tracker tickets and pull
> requests. When a pull request is merged, we would need to close manually
> the bugzilla ticket if everything is done. And when someone requests a
> pull, the person would need to add a comment manually on bugzilla so
> that other people know that the bug is being worked on.
> 
in github you can setup “hooks" and make it close bugzilla bugs when referenced 
in a commit message ("Fixes bug #12345") merged to master, so I guess gitlab 
should have something similar.

Not that I like bugzilla :), but it’s true the issues thing in github and, I 
guess, gitlab seem to be very basic compared to what you can do in bugzilla.

Rodrigo

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

Re: Gerrit?

[Rodrigo Moya]

On Fri, 2013-08-16 at 15:31 -0400, Colin Walters wrote:
 Hi,
 
 Any opinions on:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=706155
 
 ?
 
 (I use gerrit for some work projects and am quite happy with it in
  general; the interdiff support in particular is incredibly useful)
 
I've also used gerrit for some work projects, and after some initial
mess (due to not knowing the work flow), it's a great tool, so +1

cheers

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

Re: VJOURNAL (Re: GNOME Calendar app and tasks)

[Rodrigo Moya]

On Wed, 2013-06-12 at 12:32 +0200, Pierre-Yves Luyten wrote:
 On Sun, 17 Feb 2013 16:32:26 -0500, Erick Pérez Castellanos
 eric...@gnome.org wrote:
  
  Just curious - is there a plan to integrate tasks in future Calendar
  app?
   https://live.gnome.org/Design/Apps/Calendar [1]
  
  Right now I'm a little short of time. But I'll keep working on it.
  
 
 
 Hi!
 
 here is a ping request for comments if any:
 
 * Contacts has already a super cool implementation
 * Calendar has too =) , and shall integrate tasks.
 
 
 = Remaining one : memos, ie,  VJOURNAL. Not sure anyone on earth use
 it...
 Do you think VJOURNAL is for gnome-calendar? since it has start date /
 end date?
 
 Or rather for Notes application? since its notes (this one is my POV,
 but not a strong opinion)... In such case I'll look for implementing
 this on my side.
 
 
VJOURNAL spec was designed with plain text (without any format) in mind
for the description of the journal entry/note. That's a big drawback,
and even though you can in theory add formatted text (like Tomboy's
pseudo HTML/XML), it will break cooperation with other VJOURNAL
software, as they will be unable to display the formatted text. Not sure
if you are really seeking that, but it's important to have it in mind.

On the other hand, supporting VJOURNAL for notes gives you instant
access to every calendar/tasks backend supported in e-d-s, as the
protocol/format/etc is the same as for calendars and tasks.

cheers


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

Re: Design in the open

[Rodrigo Moya]

On Fri, 2012-04-27 at 11:23 +0100, Allan Day wrote:
 On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote:
  2012/4/25 Allan Day allanp...@gmail.com:
 ...
  So, IMHO a design driven GNOME needs good desing documents. The
  design document is a written contract[4] between designers and other
  teams, more time you spend writing it, less time you'll spend explaing
  here on desktop devel list :)
 ...
 
 For me, design in the open is about developers and designers working
 together as partners, not hyper-specified design documents. That might
 not give observers as much to see, but it provides contributors with a
 real opportunity to shape our project. That's not something I would
 want to take away.
 
 GNOME design is often misunderstood as creating specifications that
 are handed down on tablets of stone. That's not the way it works -
 each design is typically the outcome of a process of iteration, and we
 keep on iterating right through the development process.
 
then, why not do the proposals for new designs here in d-d-l? That way
you might get initial feedback before starting on the design, and people
that feel ignored get info on what's going on. Then, you can just keep
working as you do right now, but an initial proposal on this list, as we
do for features, might be a good idea to get everyone interested
involved

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

Re: Design in the open

[Rodrigo Moya]

Hi Allan

On Wed, 2012-04-25 at 14:27 +0100, Allan Day wrote:
 Hi all,
 
 Apologies in advance for the long mail - there was no other way.
 

 There have been a few design-related threads on the list recently. I’m
 going to try and reboot those discussions in a slightly different and,
 I hope, more constructive mode.
 
yes, very constructive, so thanks a lot for stepping in and getting the
discussion to a constructive way!

 Now, there have been some initiatives in GNOME to try and help make
 design more successful within the community. Some of those are
 well-known, like the design wiki pages and the IRC channel, but there
 have been other things too, like design office hours (remember those?
 nobody came), UX Advocates (also suffered from a lack of take up) and
 Every Detail Matters. We are also working to attract more design
 contributors, which the Outreach Program for Women is really helping
 with right now (yay!)
 
I think a lot of people complain about not having an archive of what has
been discussed in design land, so even though I know you are all busy,
maybe it would be great to use the usability list to notify of ongoing
work. Just a mail linking to the design wiki pages when something new is
added/updated would be a great step. And I think it would make all the
people that complain about this have a central point of information.

just something that came to mind after seeing your very constructive
mail, so just ignore it if it doesn't make sense :)

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

Re: How do you hack on the bleeding edge of Gnome?

[Rodrigo Moya]

Hi Federico!

On Wed, 2012-04-18 at 17:55 -0500, Federico Mena Quintero wrote:
 I've been having a terrible time trying to get something tested on top
 of Gnome 3.4, all because I can't get 3.4 built from jhbuild.  I'm too
 old to build from tarballs, and my distro doesn't carry 3.4 yet.
 
 I wonder how people who hack on core Gnome do it on a day to day
 basis.
 
 Here are the results of a little poll/brainstorm on Twitter:
 https://live.gnome.org/BuildMeHarder
 
 As a quick summary, the problems we have with jhbuild are:
 
 1. Build everything before you can contribute is a *HUGE* brick wall
 for contributors both regular and sporadic.
 
 2. Jhbuild is unreliable for obscure reasons.  People don't have the
 time or skills to fix every little autotools problem that comes up -
 these seem to happen all the time (what do you mean libtool macros not
 found!?  I already built 20 modules that use libtool!).  GISCAN fails
 regularly with unknown symbols.  Etcetera.
 
 3. Packages fail to build due to missing external dependencies, but you
 don't get notifid until the package fails to build.  It's not nice to
 get a failure in NetworkManager, after half a day of building, just
 because I didn't have the distro's ppp-devel package installed.  It
 would be nicer to get notified in advance.
 
a solution for this would be to have a jhbuild package for your distro,
with all the dependencies, although that might be overkill, as it would
depend on lots of libraries, that maybe you don't need if you don't
build everything

 4. You ask on IRC, and more often than not the best answer is, wipe
 everything and try again.
 
I never do this! I prefer to have an old module around than being unable
to build everything because a base module doesn't build :-)

cheers

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

Re: Module Proposal: Zeitgeist

[Rodrigo Moya]

On Thu, 2012-04-19 at 10:31 +0100, Bastien Nocera wrote:
 On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote:
  
   Clocks: The clocks app is designed by the GNOME designers.
  It is still more
   or less a prototype I am working on alongside Emily Gonyer.
  We wanted to
   make use of Zeitgeist in storing Alarms as a type of
  scheduled event, it
   sounds like shoehorning but it is not. I am just hesitant
  because I myself
   as a GNOME member do not want to use a technology or force
  integrate it
   without GNOME agreeing of the usage of Zeitgeist.
  
  
  It might help for you to elaborate why Zeitgeist is needed
  there.
  Clocks is intended to be a really simple application.
  
  
  
  We need to be able to store Alarms. And those alarms should still work
  while the clocks application is closed. For that we need a central
  storage for the scheduled event which is the alarm, to notify all
  subscribers including Shell that an alarm went off. Same would go for
  timers. What do you think? 
 
 I think that somebody with a hammer sees every problem as a nail. You
 don't need to store alarms in Zeitgeist, you need to store the fact that
 the alarm went off in Zeitgeist.
 
why not store them in e-d-s? you can create a separate calendar,
disabled for viewing in the Evolution UI, which contains the events with
the alarms. Thus, you don't need to have anything other than the already
running evolution-alarm-notify process.

You can even, IIRC, set up the alarm so that it runs an application,
rather than showing the Evolution alarm dialog.

cheers

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

Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

[Rodrigo Moya]

On vie, 2012-01-20 at 22:56 +0100, Lennart Poettering wrote:
 On Fri, 20.01.12 08:47, Ryan Lortie (de...@desrt.ca) wrote:
 
  
  hi Bastien,
  
  On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote:
   No, the distributions/systems that choose not to use systemd will have
   to provide a compatible D-Bus service.
  
  This is what I guessed you'd say.
  
   It can be something extracted from systemd, or something new and
   revived from the old date and time mechanism, but it won't be something
   we support and maintain in gnome-settings-daemon.
  
   And I'm glad I have 3000 less lines code to maintain.
  
  I'm just a little bit concerned about how this looks.  I love when we
  can delete code, but we're doing it by disabling a previously-working
  feature for a portion of our users.
  
  If we introduced new optional features that depended on a particular
  systemd functionality in order to operate, it would be one thing.  We do
  that often.  This change is a regression of existing functionality in
  the name of I don't feel like maintaining it anymore.
  
  I'd also feel a bit better if I thought you had made efforts to get in
  touch with those that would be affected by this regression.  Ubuntu
  isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for
  the last week I've been trying to convince them that they should.  If I
  had succeeded (which I am now glad I didn't) then this change would have
  been a royal pain, creating a whole lot of new work to fit into an
  already full schedule.
  
  Many of our own end-users will still want to install GNOME 3.4 onto
  their Ubuntu systems (myself included).  I look forward to the mention
  in our release notes about how they can no longer change their time
  because we wanted to delete a bit of code.
 
 Note that The Ubuntu folks have been well aware of all of this
 coming. How I know that? Because at their last UDS they scheduled a
 session about rewriting those mechanisms for Ubuntu, and they even have
 a project page up on launchpad:
 
 https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit
 
as I already said, this is all implemented, except for the datetime
interface, which wasn't used in GNOME when I implemented the other
systemd services.

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

Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

[Rodrigo Moya]

On vie, 2012-01-20 at 04:25 +0100, Lennart Poettering wrote:
 On Thu, 19.01.12 17:49, Ryan Lortie (de...@desrt.ca) wrote:
 
  
  hi Bastien,
  
  On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote:
   commit 27fa171efe4179c0a42ec79e0dc501077f042a08
   Author: Bastien Nocera had...@hadess.net
   Date:   Thu Jan 19 22:33:21 2012 +
   
   datetime: Remove datetime D-Bus mechanism
   
   Now that gnome-control-center uses systemd's date  time mechanism[1],
   we don't need to ship our own mechanism for that purpose. This also
   removes the last user of dbus-glib in gnome-settings-daemon [2].
  
  Are there plans to provide a systemd-compatible backend for those
  systems that cannot run systemd?
 
 IIRC ubuntu did some work there:
 
 https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit
 
IIRC, the datetime one wasn't added, but yes, it should be added quite
easily, as it was done with the other DBus interfaces

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

Re: GNOME Online Accounts extensibility

[Rodrigo Moya]

On jue, 2011-10-06 at 14:30 -0400, Ken VanDine wrote:
 Sorry, not trying to sound harsh here but I couldn't find a better way
 to say this.  
 
 Basically you are saying that GOA isn't really an open technology to
 help consolidate user's online accounts, it is only to help consolidate
 accounts for blessed GNOME apps?  This doesn't really help users in the
 big picture, but I guess the design team makes those decisions.
 
GOA already has support for Twitter and Facebook accounts, they are just
disabled in the build by default because of the legal issues David
mentions.

In fact, I asked about enabling them by default recently, and David
explained the distributing-the-keys problem, which needs to be solved.
So, there's nothing to do with designers, it's just a legal issue.

Out of curiosity, what keys does gwibber use? does it distribute them?

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

Re: Features !

[Rodrigo Moya]

On jue, 2011-10-06 at 10:49 -0400, Jasper St. Pierre wrote:
 On Thu, Oct 6, 2011 at 10:36 AM, Rodrigo Moya rodr...@gnome-db.org wrote:
  On jue, 2011-10-06 at 10:31 +0100, Martyn Russell wrote:
 
  - Integration with thunderbird in the calendar (there is a red hat bug
  about this somewhere I saw recently)
 
  - Why show the wacom graphics tablet configuration page in the System
  Settings if I don't have one? (perhaps Ubuntu specific)
 
  not ubuntu specific, but yes, your are right, it shouldn't show up, or
  even better, it should be something about tablets in general, not only
  Wacom
 
 If we show it only when you plug the device in, will you know that
 there is a magic panel for Wacom tablets in the System Settings that
 appears when I plug in my newly-bought Wacom tablet? Should we pop it
 up automatically when you plug in a tablet? Maybe a notification that
 asking to configure it that opens the panel?
 
yes, that makes sense indeed. But apart from that, it should really
support all kind of tablets, not only Wacom ones :)

___
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

[Rodrigo Moya]

On Tue, 2011-06-07 at 07:24 +1200, John Stowers wrote:
 On Mon, 2011-06-06 at 13:42 +0100, Allan Day wrote:
  Dave Neary wrote:
   Hi,
   
   
   So, in short, I would like the design team to act like the gnome-utils 
   team.
  
  GNOME design has all the equivalent facilities [1, 2, 3] excluding the
  mailing list.
  
  Again, I agree (and have never disagreed) that we need to do better. The
  only question has been around the appropriateness of a mailing list.
 
 Does this mean an IRC log/bot is back off the table?
 
 I would be happy to read such logs not for accountability but because
 it allows one to learn how the design process operates (like how reading
 code can be useful as a programmer). It can also be more convenient for
 people in stupid timezones (me).
 
yesterday I asked the same question (where to follow design discussions,
apart from IRC), and I was told to monitor https://live.gnome.org/Design
and children pages, which is enough to get a peak of what they are doing
indeed.

Also, while I'm not a designer, yesterday I wanted to propose some new
stuff, and it was easy to get the design team to find a solution for
proposals (https://live.gnome.org/Design/Proposals ), so from my (short)
experience they seem to be open to listen to new ideas.

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

Re: GNOME Feature Proposal: Backup

[Rodrigo Moya]

On Wed, 2011-05-18 at 13:21 -0400, Michael Terry wrote:
 
 And also, does being in git imply that the translation team would
 automatically consider the module?
 
yes, you will start getting translations as soon as it's there. It
happened to me to several modules

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

Re: systemd as external dependency

[Rodrigo Moya]

On Wed, 2011-05-18 at 17:51 -0500, Federico Mena Quintero wrote:
 On Wed, 2011-05-18 at 21:50 +0100, Bastien Nocera wrote:
 
  Which is why I've asked Lennart to add a flag to systemd's configure to
  install only the little servicey bits, for Linux distros, and the docs
  would serve as basis for implementation of other OSes.
 
 That's fine.  I still think other distros/systems may be feel it to be a
 little onerous to have to download a big system-level package (even if
 it's just perception) to install random services like that.
 
 (Maybe a system-services tarball, if you really don't like the name of
 AdminKit?) :)
 
come on, AdminKit was such a great name! :-)

But yes, we should really standardize interfaces, so that any other OS
can easily implement them.

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

Re: systemd as external dependency

[Rodrigo Moya]

On Thu, 2011-05-19 at 12:00 +0200, Olav Vitters wrote:
 On Thu, May 19, 2011 at 11:41:08AM +0200, Sebastien Bacher wrote:
  Le jeudi 19 mai 2011 à 10:53 +0200, Olav Vitters a écrit :
   That is perfectly valid advice. You need various things in your
   distribution to help GNOME development. I would not advise anyone to
   use Ubuntu anymore when they want to get involved with GNOME. 
 
  Could you give some details on what is the issue with running Ubuntu and
  contributing to GNOME? Several active GNOME contributors are running
 
 I've seen a lot of people on IRC and during the 3.0 party saying the 3.0
 PPA killed their Ubuntu. Or that their had a lot of difficulty to get a
 jhbuild going.
 
well, we've had several problems due to having 2.91.x releases, but most
of them are now fixed, and a lot of people (including myself) are using
it daily. So yes, some people encountered problems, but most of them
were due to the unstability of the software we were packaging and some
packaging bugs on our side. I haven't heard any serious problem which
hasn't been fixed since we packaged the final 3.0

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

Re: systemd as external dependency

[Rodrigo Moya]

On Wed, 2011-05-18 at 22:50 +0200, Jasper Lievisse Adriaanse wrote:
 I think I can say that I speak for the whole BSD community, GNOME users
 and non-GNOME users, when I say that such steps as enforcing Linux-only
 dependencies even more is a clear sign GNOME does not care about portability
 to any OS other than Linux...and that this is very sad sign to everyone else.
 
not directed at you personally, sorry, but every time someone gives a
personal opinion, there's someone (like you in this thread) that takes
that granted as the official GNOME position.

So please, let's not do this anymore, personal opinions are personal
opinions, not representative of the whole project.

___
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 Re: GNOME Feature Proposal: Backup]

[Rodrigo Moya]

On Wed, 2011-05-11 at 11:55 +0100, Bastien Nocera wrote:
 On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote:
  So as the Deja Dup maintainer, life will go on when you drop support.
  Worst case, I can just make the panel a dialog.
  
  But dropping the existing API feels like a frustrating bait and
  switch.  It was not clear (at least to me) that this was your
  intentional all along, so myself and others made plans and put effort
  into making panels.
  
  Maybe next time you could whitelist the plugins you want or force
  people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties
  don't waste time.
 
 I understand it's frustrating, but I don't remember anyone asking
 whether this API was considered stable, or anything of that kind. We
 have a couple of people working close to full time on the
 control-center, so those questions would certainly get answered.
 
 We thought that third-party developers would put some work into
 integrating their functionality within the control-center, instead, we
 were stumped when we saw the Input methods panel, which was a straight
 port from GNOME 2.x instead of something integrated in the Region 
 Language panel.
 
hmm, where's that Input methods panel code? We indeed want it go through
design and integrated into the Region  Language panel

___
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]

[Rodrigo Moya]

On Thu, 2011-05-12 at 22:58 +0100, Sergey Udaltsov wrote:
  We're not dictating anything; we're just making an awesome OS, the way
  we envision, period.
 Wait a sec. It was said (here and on IRC) that g-c-c wants to include
 only polished panels to g-c-c. Only panels that gnome UI specialists
 are happy with. It is a form of dictate - or I do not know what
 dictate is. Or did I misunderstand some statements? In a way, even HIG
 itself is a dictate - a relatively weak form of it (but at least put
 into the document, which is the best thing about HIG!)
 ___

well, it's really a way of asking people interested in having stuff in
g-c-c to cooperate with GNOME designers and developers.

Apart from that, that's how every piece of GNOME software works:
maintainers include what they are happy with, not everything anyone
wants to add.


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

Re: New module proposal: LightDM

[Rodrigo Moya]

On Fri, 2011-05-13 at 17:41 -0400, Colin Walters wrote:
 On Fri, May 13, 2011 at 12:55 PM, Robert Ancell robert.anc...@gmail.com 
 wrote:
 
  There have been problems for years and years and years.  There is some
  point where you need to reconsider if that strategy is appropriate.
 
 So here's some actual data:
 
 https://bugzilla.gnome.org/buglist.cgi?cf_gnome_target=---;cf_gnome_version=---;query_format=advanced;emaillongdesc1=1;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;bug_status=RESOLVED;bug_status=VERIFIED;email1=robert.ancell%40gmail.com;product=gdm;emailtype1=substring
 
 It looks like to your credit, you have submitted patches; some like
 https://bugzilla.gnome.org/show_bug.cgi?id=596831 have been accepted,
 others like https://bugzilla.gnome.org/show_bug.cgi?id=593996
 discussed, considered, and rejected.  The latter one is obsoleted now
 by the accounts service anyways.
 
 I'm not convinced by this data that GDM has been a problematic code
 base to work on.  You're obviously free to create a new project; but
 on the basis above, I'd say you really didn't try very hard to make
 real changes in GDM before deciding to rewrite from scratch.
 ___

even though I don't have real data here, I must say that I know Robert
has been working on GDM a lot of time, so this is not fair really.

Also, AFAIK, most distributions carry an insane amount of patches in
their GDM packages, so that seems to mean something (not sure what
though, not an expert on login managers myself).

So, maybe other considerations for rejecting LightDM might apply, but
for sure Robert's attempts to work on GDM to fix issues there does not
apply at all.

cheers


___
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 Re: GNOME Feature Proposal: Backup]

[Rodrigo Moya]

On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote:
 So as the Deja Dup maintainer, life will go on when you drop support.
 Worst case, I can just make the panel a dialog.
 
 But dropping the existing API feels like a frustrating bait and
 switch.  It was not clear (at least to me) that this was your
 intentional all along, so myself and others made plans and put effort
 into making panels.
 
while I'm not sure making the API private is the best idea, I really
understand the reasons behind that decision, which is to not allow for a
control-center crowded with lots of crazy panels, specific to
applications.

But backup is indeed something that makes a lot of sense as a System
Settings panel, so I think it could probably be integrated into
gnome-control-center itself. So, what are the dependencies the c-c panel
in Deja Dup has?

So, getting some design for this would be a good thing, so that we can
start integrating it into the control center itself.

Also, another solution might be to keep the g-c-c API public, but have a
whitelist, so that we just list there the panels that we bless and that
will be loaded in the g-c-c shell. Others would just be ignored, and so
distributions can choose to add the panels they want to the whitelist.

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

Re: GNOME Feature Proposal: Backup

[Rodrigo Moya]

On Tue, 2011-05-10 at 20:51 +0100, Bastien Nocera wrote:
  I suspect GNOME might be interested in having a backup story so I'm
  offering this one.  And I'd be happy to have increased design advice
  and developer eyeballs.
 
 I'd really like Deja Dup to be even more integrated into the system,
 meaning that we should make it possible to backup the whole system,
 using fanotify(), and possibly integrating with btrfs snapshots.
 
I don't think we should aim for whole system backup really, but just
user's data backup should be enough. Administrators know perfectly how
to backup their systems

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote:
 On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote:
  On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote:
   
   Regarding couchdb: how complete is its data model? When it first
   showed up, SyncEvolution had some problems with it because REV wasn't
   supported, if memory serves me right.
   
  IIRC, that was a bug you filed for evolution-couchdb, which didn't
  include the REV field, which I fixed some months ago.
 
 Does it support arbitrary vCard extensions?
 
evolution-couchdb supports whatever Evolution supports, which has
several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it
does

As for couchdb, it's a schema-free database, so it can support whatever
we want it to

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 09:43 -0700, Travis Reitter wrote:
 On Tue, 2011-04-19 at 13:48 +0200, Rodrigo Moya wrote:
  On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote:
   As Frederic pointed out, we shouldn't be brainstorming on the 3.2
   feature pages, so I thought I'd fill in some details/thoughts on the
   Contacts [1] idea here.
   
   The page suggests libfolks and/or libsocialweb for the implementation.
   The good news is that Folks 0.5.0 (released last week) added support for
   libsocialweb, so using Folks gets you both. In the process, Alban Crequy
   also added Contacts support for a few libsocialweb services in
   libsocialweb itself (Flickr, Twitter, Last.FM) and upstreamed Marco
   Barisione's Facebook support. The remaining lsw services (such as Vimeo
   and YouTube) don't have Contacts support yet, but it could certainly be
   added.
   
  this makes a lot of sense, but we really need a way to send messages to
  facebook/twitter contacts, or do other operations on the other services
  (see photos from flickr, listen to music in last.fm, etc).
  
  So, are there any plans for a twitter/facebook client app?
 
 None that I know of. We already support Facebook's XMPP chat through
 Telepathy but not its email-like messaging system. Can third party
 clients use that anyhow? I thought that was completely walled off.
 
 I'm not terribly familiar with the details of Twitter - it just supports
 140-char global posts and private messages between users, right?
 
yes

 Handling sending these messages is probably best implemented as protocol
 handlers for Evolution, since they don't quite fit in with Telepathy's
 model and I think libsocialweb avoids communication to keep its scope
 narrower.
 
it doesn't quite fit into Evolution neither, afaics. The private
messages between users do, right, but not the global posts. Showing that
as email messages might work, not sure, but it doesn't sound too right
to me. Ditto for IM, so that's why I think a separate app, well
integrated into the shell, might be the way to go

 There's also the question of whether we should be encouraging people to
 use Facebook's or Twitter's private message systems when email is quite
 a bit more open/easily-accessible/user-controlled.
 
I was talking about public posts, not private messages

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Wed, 2011-04-20 at 11:54 +0200, Patrick Ohly wrote:
 On Mi, 2011-04-20 at 10:58 +0200, Rodrigo Moya wrote:
  On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote:
   On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote:
On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote:
 
 Regarding couchdb: how complete is its data model? When it first
 showed up, SyncEvolution had some problems with it because REV wasn't
 supported, if memory serves me right.
 
IIRC, that was a bug you filed for evolution-couchdb, which didn't
include the REV field, which I fixed some months ago.
   
   Does it support arbitrary vCard extensions?
   
  evolution-couchdb supports whatever Evolution supports, which has
  several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it
  does
 
 I was thinking of extensions not yet used by Evolution. Let's use an
 example: is an extensions like X-FOOBARAPP-MY-NEW-PROPERTY going to be
 stored by evolution-couchdb when it appears in a vCard sent to EDS?
 
not right now, it's a bug indeed. But the desktopcouch spec in
freedesktop has a field called 'application_annotations', where we could
store any field evolution-couchdb doesn't understand.

 This is relevant in several cases:
  1. when extending the data model in Evolution and/or apps using
 libebook
  2. when storing/retrieving vCards created by some other app
 
 Case 1 occurs when using EDS as backend for QtContacts, the contact API
 in MeeGo. I'm currently working on that binding, with the goal of
 getting EDS back into MeeGo.
 
 Case 2 already occurs in GNOME when synchronizing. It can be handled by
 SyncEvolution by declaring which properties are supported by a storage,
 but right now the assumption is that EDS backends are as capable as the
 file backend and support arbitrary extensions.
 
  As for couchdb, it's a schema-free database, so it can support whatever
  we want it to
 
 How hard would it be to add storing such extensions and recreating them
 again later? Remember that they may also contain X- parameters and that
 binary encoding needs to be handled.
 
not hard at all, we just need to define where they are stored (that is
application_annotations/evolution, for instance) and add the code to
evolution-couchdb to do so

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote:
 On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote:
  On 19 April 2011 11:27, Alexander Larsson al...@redhat.com wrote:
   On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote:
   another very important point is synchronisation. together with salomon
   sickert we thought about how to solve this problem. basically we came up
   with the idea of a self-replicating backend, like couchdb. if we then
   could add support to the contact apps of other computer/devices like a
   n900 or android, we would get synchronisation and conflict management
   for free.
  
   then there is also the idea of having a webservice for the gnome
   contacts app, where you can access your contacts over the internet.
  
   we are very interested in your opinions about this!
  
   I don't know really. Synchronization is a tricky subject, with complex
   protocols and risk for merge problems. Its almost always a source of
   weird problems. I don't think we want to have synchronization as some
   core part of the design.
  
   On the other hand, its important that there is some level of support for
   synchronizing contacts with e.g. phones. So, I guess we need to think
   about where it fits in.
  
  If you start to talk about synchronisation, please talk to Patrick
  Ohly patrick.o...@gmx.de.  He maintains SyncEvolution that is
  probably the only working PIM syncing tool that I know of, and it's
  totally non-trivial.
 
 you mean kinda-working? ;) indeed, synchronisation with todays devices
 over syncml is extremely hard. i really don't want that in the core
 design neither.
 
 i was more thinking about a backend like couchdb, which has a
 synchronisation solution already built in. ubuntu does that for example
 with evolution and ubuntu one.
 
evolution-couchdb provides that already, so if folks has an e-d-s
backend, it should already be available. Also, replication/conflict
management in couchdb is quite good indeed

The problem with this is that for couchdb to be really useful, the
best thing is to run a local instance that then syncs to a remote
instance, and while it's entirely possible (as you said, Ubuntu One does
it) some people showed their concerns when I proposed
couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a
local instance of couchdb.

But yes, should be perfectly possible. Maybe we should revisit the
discussion again?

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote:
 As Frederic pointed out, we shouldn't be brainstorming on the 3.2
 feature pages, so I thought I'd fill in some details/thoughts on the
 Contacts [1] idea here.
 
 The page suggests libfolks and/or libsocialweb for the implementation.
 The good news is that Folks 0.5.0 (released last week) added support for
 libsocialweb, so using Folks gets you both. In the process, Alban Crequy
 also added Contacts support for a few libsocialweb services in
 libsocialweb itself (Flickr, Twitter, Last.FM) and upstreamed Marco
 Barisione's Facebook support. The remaining lsw services (such as Vimeo
 and YouTube) don't have Contacts support yet, but it could certainly be
 added.
 
this makes a lot of sense, but we really need a way to send messages to
facebook/twitter contacts, or do other operations on the other services
(see photos from flickr, listen to music in last.fm, etc).

So, are there any plans for a twitter/facebook client app?

For photos and music, I guess it's easy, since we can't just start the
corresponding app/url from the 'contacts view' in the shell


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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 13:28 +0200, daniel g. siegel wrote:
 On Tue, 2011-04-19 at 13:21 +0200, Rodrigo Moya wrote:
  On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote:
   On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote:
On 19 April 2011 11:27, Alexander Larsson al...@redhat.com wrote:
 On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote:
 another very important point is synchronisation. together with 
 salomon
 sickert we thought about how to solve this problem. basically we 
 came up
 with the idea of a self-replicating backend, like couchdb. if we then
 could add support to the contact apps of other computer/devices like 
 a
 n900 or android, we would get synchronisation and conflict management
 for free.

 then there is also the idea of having a webservice for the gnome
 contacts app, where you can access your contacts over the internet.

 we are very interested in your opinions about this!

 I don't know really. Synchronization is a tricky subject, with complex
 protocols and risk for merge problems. Its almost always a source of
 weird problems. I don't think we want to have synchronization as some
 core part of the design.

 On the other hand, its important that there is some level of support 
 for
 synchronizing contacts with e.g. phones. So, I guess we need to think
 about where it fits in.

If you start to talk about synchronisation, please talk to Patrick
Ohly patrick.o...@gmx.de.  He maintains SyncEvolution that is
probably the only working PIM syncing tool that I know of, and it's
totally non-trivial.
   
   you mean kinda-working? ;) indeed, synchronisation with todays devices
   over syncml is extremely hard. i really don't want that in the core
   design neither.
   
   i was more thinking about a backend like couchdb, which has a
   synchronisation solution already built in. ubuntu does that for example
   with evolution and ubuntu one.
   
  evolution-couchdb provides that already, so if folks has an e-d-s
  backend, it should already be available. Also, replication/conflict
  management in couchdb is quite good indeed
  
  The problem with this is that for couchdb to be really useful, the
  best thing is to run a local instance that then syncs to a remote
  instance, and while it's entirely possible (as you said, Ubuntu One does
  it) some people showed their concerns when I proposed
  couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a
  local instance of couchdb.
  
  But yes, should be perfectly possible. Maybe we should revisit the
  discussion again?
  
 
 imho couchdb is just one way of many, but certainyl the right direction.
 you guys showed, that it is possible to have a working synchronisation
 quite easily with couchdb. so yes, let's re-evaluate possible backends?
 
what do you mean by 'backends'? Backends of what? As I said,
evolution-couchdb already provides an e-d-s backend for accessing
contacts in CouchDB databases, so IMO, what we need is:

* a user service that starts a local couchdb instance

* a way for evo-couchdb to know at what port that instance is listening
(if it's random, maybe we could establish a standard one). With
desktopcouch (the Ubuntu One local couchdb instance), we do a DBus call
to obtain the port, but that's quite tricky, as couchdb can crash and
thus start on a different port. Another option would be to provide a
full DBus service that allows access to that local instance, regardless
of the port, but then we'll need to write lots of new code to talk to
that service, as evolution-couchdb just talks the CouchDB protocol
(http://wiki.apache.org/couchdb/Reference) which works for any couchdb
instance, whether it's local or remote.

* a tool to configure where to replicate the local instance to

* authentication for the local and remote instances. couchdb-glib (the
API implementing the couchdb client-side protocol) already supports
OAuth and user/password authentication

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 14:38 +0300, Jens Georg wrote:
 On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote:
  and right here i think we shouldn't base on bad formats (vcard) and
  sucking protocols (syncml). using json is a much better option.
 
 Well as soon as you talk about sync, someone says device. And devices
 come with vCard.
 
  see for example the desktopcouch specification for contacts
  http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact
 
 Looking at this - do you realise how much very much that matches the
 vCard spec? That's basically a vCard translated to JSON.
 
well, that's because the fields used to describe a contact are quite
obvious, so it's not a vcard-json translation really, it's just a set
of fields to describe a contact, which happen to be also in vCard

 Personally, I'd rather have a root canal treatment than couch db
 hammering my computer, but I like the auto-replication idea.
 
auto-replication of several instances and, most important, conflict
management for free :-)

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 14:14 +0200, daniel g. siegel wrote:
  what do you mean by 'backends'? Backends of what? As I said,
  evolution-couchdb already provides an e-d-s backend for accessing
  contacts in CouchDB databases, so IMO, what we need is:
 
 so my question is basically: why do we need e-d-s if we have our
 contacts in couchdb?
 
ah ok, I see what you mean. We need e-d-s for Evolution to access the
contacts, and if libfolks already has an e-d-s backend, it will get
contacts for every addressbook configured in Evolution, right?

If not, yes, just using couchdb-glib directly in whatever 'backend' you
want works.

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

Re: ThreePointOne: Contacts

[Rodrigo Moya]

On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote:
 
 Regarding couchdb: how complete is its data model? When it first
 showed up, SyncEvolution had some problems with it because REV wasn't
 supported, if memory serves me right.
 
IIRC, that was a bug you filed for evolution-couchdb, which didn't
include the REV field, which I fixed some months ago.

As for couchdb, each document has a unique, cross-database revision
number

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

Re: Idea: Command search

[Rodrigo Moya]

On Wed, 2011-04-13 at 14:04 +0100, Who wrote:
 On Tue, Apr 12, 2011 at 10:32 PM, Mirek M. maz...@gmail.com wrote:
  Hi everyone,
  I realize that plans for Gnome 3.2 are being determined, and I just want to
  put an idea out there.
  What I'd really love to see in Gnome is command search for every
  application, much like Mac OS X has *.
  This search should reside in the Application menu, and should, if possible,
  also be based on menu items. Developers should, of course, also have the
  option of adding commands not available under menus and of adding tags to
  their commands, to make search more relevant.
  Do you think this would be possible? Would there be any major hurdles to
  overcome before this can be implemented (besides with applications that
  don't use the native GTK menu widget)?
 
 I've been hoping for an API like this for some time, as it would
 enable gnome-do/quicksilver/etc integration with applications
 themselves.
 
 Workflows like file-save as can be done very elegantly for a power
 user by gnome-do style interaction, but it requires integration with
 the apps themselves.
 
 My suspicion is that Mac OS uses its accessibility APIs to work with
 menus like that - is that an option for GNOME?

it should be right? That is, we have access via ATK to all the apps'
menus

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

Re: Metacity towards GNOME 3.0

[Rodrigo Moya]

On Wed, 2010-12-01 at 16:29 -0500, Owen Taylor wrote:
 Metacity is an important component of GNOME 3 as the window manager in
 fallback mode. There's a couple of major things that need doing to make
 it work in the GNOME 3 stack that I wanted to bring up here. Both of
 them already have patches but we need to figure out exactly we want
 to do.
 
 Port to GSettings
 =
 https://bugzilla.gnome.org/show_bug.cgi?id=621204
 
 Mutter and Metacity share most of their configuration keys and these
 keys are also accessed by gnome-control-center and
 gnome-settings-daemon.
 
 In order to meaningfully make GNOME 3 a GSettings-based desktop;
 something that can be managed in one place through one system, we need
 to migrate these keys over to GSettings.
 
 The main question in my mind is where they live. Right now, Mutter
 requires Metacity.
 
  - For the GConf schemas
  - For:
  gnome-control-center/keybindings/50-metacity-desktop-key.xml
  gnome-control-center/keybindings/50-metacity-key.xml
  - For the default theme Atlanta
 
 So our options here are:
 
  - Leave everything in Metacity, keep requiring Metacity as a dependency
of Mutter. This isn't really a problem for GNOME 3.0, but we'd
like to drop this dependency eventually and the migration to 
GSettings is a natural time to move things around.
 
  - Have a separate module like gnome-wm-data with the GSettings schemas,
XML files and keys.
 
  - Move the GSettings schemas and the closely linked keybinding XML
to gsettings-desktop-schemas and do something else for the theme
for Mutter. We could just switch Mutter to depend on
gnome-themes-standard and default to Adwaita. 

 I'm most in favor of the third option though there is some issue with
 either the second or third option in terms of the way key bindings work
 in Metacity  the Metacity GConf schema has the keys for key bindings
 generated and inserted via a program working from the same header files
 that are used in the code.
 
We have been moving all desktop-wide settings to
gsettings-desktop-schemas, so I guess it makes sense to have them there,
under org.gnome.window-manager (or something similar), and just have
metacity and mutter depend on it

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

Re: Holes in GNOME 3 process

[Rodrigo Moya]

On Tue, 2010-11-30 at 16:26 -0500, Owen Taylor wrote:
 
 Plans for testing GNOME 3
 =
 Everybody knows what needs work in their own modules, but there are lot
 of gaps in between modules. How are we going to catch options in the
 control center not doing anything, etc?
 
what do you mean with this? There are indeed a few things the new
control center is waiting for, like what to do with the /apps/metacity/*
config keys

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

Re: (not) proposing Snowy for GNOME 3.0

[Rodrigo Moya]

On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote:
 
 
 == GNOME Web Platform ==
 
 There is no GNOME web platform.  There are no new libraries being
 proposed for use by all GNOME web modules.  It feels way too early to
 try to make those sorts of decisions.  We need another module or two
 before we discover what can and should be shared.
 
 I will say that even if we end up with an Online Desktopish goal, we
 should not strive for one big monster web app.I think it makes
 sense to focus on smaller, single-purpose web apps with sensible
 integration points.
 
 For example, we could have a Mugshot-like identity app for Teh
 Social, and have it aggregate info from apps like Snowy.  We could tie
 apps together with existing standards like OpenID and OAuth.  We could
 come up with conventions for building RESTful APIs, standardize on
 JSON, etc etc.  We could build standard GTK+ widgets for
 authenticating with GNOME web services.  Whatever makes sense to make
 integration between the GNOME desktop and the GNOME web easy on
 developers and users.
 
yes, maybe it would make sense to have a generic sync API, so that the
same API and server could be used for syncing notes, contacts, calendar
events, etc. I don't think that would make a monster app, if it's just
a syncing server implementing a single API, wouldn't it?

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

Re: GNOME 3.0 in March 2011

[Rodrigo Moya]

On Thu, 2010-07-29 at 09:56 +0200, Bastien Nocera wrote:
 On Thu, 2010-07-29 at 09:24 +0200, Frederic Peters wrote:
  Paolo Borelli wrote:
  
   I still would like to have a definitive description of what 2.32 apps
   can and cannot use: for instance will the new glib be part of the
   release (and hence gsettings etc)?
  
  There will be both a glib and a GTK+ 2.x release in September; modules
  should still be ported to use GSettings, hopefully a GtkApplication
  backport will land soon in GTK+ and module are encouraged to use it.
  
  Also the GTK+ 3 migrating story (get your module building with gseal,
  without using deprecated parts, and it will work) should still hold
  true; there was a GTK+ meeting yesterday, probably they will send
  minutes and a detailed status update.
  
  In the specific case of gedit, there's the issue of libpeas, it is
  really your call if you want to start using it already in 2.32.
 
 Given that apps that wanted to port to GSettings are already ported, I
 really don't see why we're advising to use GTK+ 2.x/3.x selection at
 configure-time when we've been telling people to target GTK+ 3.x.
 
 Speaking about my modules, I will not accept any changes to make them
 work with GTK+ 2.x again, nor would I want people to waste their times
 doing that.
 
 The 2.32 story is inexistent: Hey, you have a couple of weeks to
 release something that you didn't plan for, and that didn't exist.
 
right, because of this, I think 2.32 should just be 2.30 + some
backported changes. If we release 2.32 with some modules using
gsettings/gtk3/etc and others not using it, we end up having 2.32 =
gnome 3 beta, don't we?

As for control-center and gnome-settings-daemon, we are going to just
backport some fixes and release that as 2.32

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

Re: GNOME 3.0 in March 2011

[Rodrigo Moya]

On Thu, 2010-07-29 at 14:26 +0200, Bastien Nocera wrote:
 On Thu, 2010-07-29 at 12:54 +0200, Rodrigo Moya wrote:
 snip
  right, because of this, I think 2.32 should just be 2.30 + some
  backported changes. If we release 2.32 with some modules using
  gsettings/gtk3/etc and others not using it, we end up having 2.32 =
  gnome 3 beta, don't we?
  
  As for control-center and gnome-settings-daemon, we are going to just
  backport some fixes and release that as 2.32
 
 For 2.32, for those modules, I would recommend:
 - branch off the latest stable 2.30 branch
 - cherry-pick any fixes from master that involve string changes
 - release :)
 
yes, that's what Thomas started doing today

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

Re: GNOME 3.0 in March 2011

[Rodrigo Moya]

On Thu, 2010-07-29 at 15:00 +0200, Xavier Claessens wrote:
 
  - dconf won't be part of that release
 
 Really? So what will happens for apps that are already ported to 
 GSettings, like Empathy?
 
well, they should be part of the GNOME 3 beta, not of 2.32.

Again, we can't do a 2.32 release with some modules using dconf, others
using gconf, etc. If we can do that, why not just keep with the 3.0 in
September 2010 plan and just have both gconf/dconf running? Since we
don't want to do that, I think we shouldn't have 2.32 mixing
technologies, so my vote is for 2.32 = 2.30 + some backporting of bug
fixes and features

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

Re: libnotify and GNOME 3

[Rodrigo Moya]

On Wed, 2010-06-23 at 09:43 -0400, Matthias Clasen wrote:
 On Wed, Jun 23, 2010 at 5:12 AM, Richard Hughes hughsi...@gmail.com wrote:
  libnotify is the only major library that I'm unclear on for GNOME 3.
  It's a conditional buildrequire in all my GNOME projects (as libnotify
  still uses gtk2.0) and I'm sure we should have a more compelling
  vision for notifications in GNOME 3.0. Does libnotify just require
  building against gtk3 or do we need a bigger rethink?
 
  I'm wondering if there has been any discussions on notifications or
  even any API? Specifically for the shell I guess, but it would be nice
  for it to work in a GNOME 2.x fallback environment too.
 
 
 I intend to add notification api in GTK+ (now that we can use dbus,
 there's no real reason anymore to put this in a micro-lib). But I need
 some input from the shell/design side on how notification etc are
 going to look in the GNOME3 world.
 
cool! but please don't forget to add buttons/something for users to
react on notifications to the notifications. Without this, notifications
are almost useless for many cases

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

Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90

[Rodrigo Moya]

On Sat, 2010-06-12 at 22:36 -0400, Michael Terry wrote:
 On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote:
  Ubuntu told me that Maverick (the next ubuntu release) is not going to ship
  GTK3
 
 I don't think that's true.  I was at the planning session for coming
 changes in GNOME at UDS Maverick, and the plan of record was to
 include GTK+ and GNOME 3.0.
 
 https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome
 
seems the situation has changed, and GTK3 will be available in Universe,
but not on the CD, and all apps are going to be linked against GTK2

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

Re: Modulesets Reorganization

[Rodrigo Moya]

On Wed, 2010-06-02 at 13:19 +0200, Andre Klapper wrote:
 Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti:
  if you want to develop for GNOME, then install a jhbuild
  sandbox (stable or development) and make your application build and work
  inside it.
 
 Depends on how you define build and work, but pretty exactly half of
 the current module maintainers already fail with fulfilling such a
 requirement. See stats at http://build.gnome.org/ . ;-)
 
just had a quick look at gnome-settings-daemon, and it's failing because
of missing X* data types, so I guess it's missing some dependencies?
Maybe that's the same for lots of other modules?

In fact, when running jhbuild from scratch, I always end up having to
install several xorg-*-dev packages.

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

Re: Module Proposal: Zeitgeist

[Rodrigo Moya]

On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote:
 
 I think you can:
 * use bzr-git to push your Launchpad trunk to GNOME git
 * setup an import of the git branch and make it trunk

launchpad just imports git master, right?

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

Re: GSettings and you

[Rodrigo Moya]

On Thu, 2010-04-22 at 09:27 -0400, Matthias Clasen wrote:
 On Thu, Apr 22, 2010 at 8:03 AM, Rodrigo Moya rodr...@gnome-db.org wrote:
  On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote:
  On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com 
  wrote:
   Nice. Just a question: where can I find the code for the Several fully
   functional backends? Especially the gconf one.
  
 
  The gconf backend is included in GConf 2.31.1.
  GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' 
  backend.
 
  and how do you write/install/setup other backends? I see you must
  implement the GSettingsBackend class, but how can you set it up so that
  all calls to gsettings_* API use it? Via the env var?
 
 
 To write your own backend (which I don't think you really want to
 do...), you implement GSettingsBackend. To use, you can either bind it
 to a special context (similar to what I explained for the keyfile
 backend), via
 
 g_settings_backend_setup (blah, backend)
 
 Or you can make your backend implement the gsettings-backend
 extension point (and possibly build it as a GIO module and install it
 in /usr/lib/gio/modules). If you do that, GSettings will consider your
 backend like any other when looking for the default. And you can
 influence the choice of the default backend by setting the
 GSETTINGS_BACKEND env var.

that's what I'd prefer, since my backend would be a couchdb-based one,
so you could just choose it as default and get all settings synchronized
to other couchdb instances. Thanks for the info, but I'm sure I'll keep
asking more questions on IRC :D


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

Re: GSettings and you

[Rodrigo Moya]

On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote:
 On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote:
  Nice. Just a question: where can I find the code for the Several fully
  functional backends? Especially the gconf one.
 
 
 The gconf backend is included in GConf 2.31.1.
 GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend.

and how do you write/install/setup other backends? I see you must
implement the GSettingsBackend class, but how can you set it up so that
all calls to gsettings_* API use it? Via the env var?

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

Re: Module Proposal: Zeitgeist

[Rodrigo Moya]

On Thu, 2010-04-22 at 08:10 +0200, Mikkel Kamstrup Erlandsen wrote:
 
 As for VCS and bug tracking it'll be quite a lot more work on our part
 if we should move. I don't think anyone in the team is directly
 opposed to the idea, but it's more the fact that it would be a major
 inconvenience. We make heavy use of Launchpad's branc/review features
 and integration with blueprints and bugs. Of course we can replace
 this with a hand held combination of bugzilla and wikipages, but it
 would be a major change in our workflow.
 
I do the same for couchdb-glib and evolution-couchdb: the code is in
GNOME Git, and imported in Launchpad, so you still can branch, propose
stuff for reviewing, and then, when branches are accepted, you just
merge it to GNOME Git (I do it by hand, because I haven't had much time
to look at bzr-git, but it should be possible, I think, to just merge
from the bzr branch to GNOME Git).

Only problem I've found doing so is that launchpad only imports Git
master, so it doesn't work for Git branches, if you use them

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

Re: Appearance properties

[Rodrigo Moya]

On Tue, 2009-11-10 at 11:28 +0100, Xavier Claessens wrote:
 Le mardi 10 novembre 2009 à 10:19 +, Thomas Wood a écrit :
  On Tue, 2009-11-10 at 10:18 +0100, Xavier Claessens wrote:
   So if you agree/disagree with those changes, please tell your opinion!
   I would like to know if I'm the only one to be worried. 
  
  Well, I'll repeat what I said on the bug:
  
  I agree with McCann, if someone wants to tweak their settings in such a
  way, then it should be done through an appropriate tweaks application.
  The interface tab does not contain options that are of interest to the
  majority of users.
 
 Can you please tell me what's gnome-appearance-properties if it is not
 to tweak the appearance of the GNOME desktop?
 
 The fact that those options are useless for the majority of users is
 highly debatable and should definitely not depend on you+McCann alone. I
 would like wider acceptance before.
 
even though I don't like much the change, this was discussed not only
between Thomas and Jon, it was discussed on the gnome-control-center
list as well, iirc, as d-d-l, so the decision has been made after a lot
of discussion (and previous bashing)

So instead of making this thread bigger, why don't people go to write a
'Interface' capplet, starting with what there was on the Interface tab?
If it's done correctly, we can even think about including it in
gnome-control-center! :)

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

Re: Appearance properties

[Rodrigo Moya]

On Tue, 2009-11-10 at 17:00 +0200, Peteris Krisjanis wrote:
 Google for 'PulseAudio Hate' and then maybe try to understand what
 dangerous road have GNOME project taken last two releases.

wow, I just googled, and yeah, you're right! but don't worry, we are
sending Lennart to an empty island without Internet soon, just be
patient

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

RE: Appearance properties

[Rodrigo Moya]

On Tue, 2009-11-10 at 15:41 +0100, Uros Nedic wrote:

 
 I'm more than ready to help to improve the things and also
 I want to become one of significant contributors, but first
 I do not know how many developers GNOME have and its
 responsibilities, I do not know how whole life-cycle goes,
 etc. I mean I know something but not on satisfying level
 to be able to develop.
 
start working on some GNOME module of your choice (hint: interface tweak
capplet in gnome-control-center :) and you'll start knowing all that and
much more :D


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

Re: Module proposal: dconf

[Rodrigo Moya]

On Thu, 2009-10-15 at 11:24 +0100, Ghee Teo wrote:
 Rodrigo Moya wrote:
  On Tue, 2009-10-13 at 23:06 +0200, Luca Ferretti wrote:

  2009/10/13 Rodrigo Moya rodr...@gnome-db.org:
  
  Ryan is a bit sad to not get feedback on his proposal, so a bit more
  seriously: I think what we probably need is a migration plan. Should we
  move all the code from gconf to dconf in one cycle (if possible)? Should
  apps implement migration for the data in gconf? etc.
 
  
  I think it makes sense to do the migration for all the apps at once.

  Are we speking about:
a) all GNOME Desktop applications
b) all applications hosted on git.gnome.org
c) all GNOME/GTK+ apps using GConf :)
 
  ??
 
  Serius: what's the plan for thirdy part applications?
  
 
  if dconf listens to changes in gconf, 3rd party apps would just need to
  link to glib/GSettings instead of libgconf, and their migration would be
  done automatically, right?

 If dconf listens to changes in gconf, does not 3rd party apps would just 
 work?
 This is a question of run-time interoperability, is dconf inter operate 
 with gconf clients?
 Please clarify this. I can see lots of reasons why 3rd party doesn't 
 want to re-link to glib/GSettings :)
 
this is for doing the migration, once apps are ported to GSettings API
(and hence not linking against libgconf), their settings should be in
the dconf database automatically, because dconf migrated them

That's how I would see it

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

Re: Module proposal: dconf

[Rodrigo Moya]

On Tue, 2009-10-13 at 23:06 +0200, Luca Ferretti wrote:
 2009/10/13 Rodrigo Moya rodr...@gnome-db.org:
  Ryan is a bit sad to not get feedback on his proposal, so a bit more
  seriously: I think what we probably need is a migration plan. Should we
  move all the code from gconf to dconf in one cycle (if possible)? Should
  apps implement migration for the data in gconf? etc.
 
  I think it makes sense to do the migration for all the apps at once.
 
 Are we speking about:
   a) all GNOME Desktop applications
   b) all applications hosted on git.gnome.org
   c) all GNOME/GTK+ apps using GConf :)
 
 ??
 
 Serius: what's the plan for thirdy part applications?

if dconf listens to changes in gconf, 3rd party apps would just need to
link to glib/GSettings instead of libgconf, and their migration would be
done automatically, right?


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

Re: Module proposal: dconf

[Rodrigo Moya]

On Wed, 2009-10-14 at 17:39 +0100, Alberto Ruiz wrote:
 2009/10/14 Xavier Claessens xclae...@gmail.com:
  Le lundi 12 octobre 2009 à 11:27 -0400, Ryan Lortie a écrit :
  I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop
  release set.
 
  This is great news! I'm all in favor of dconf. Do you have plans to move
  to GNOME plateforme? IMO that really should replace gconf for GNOME3,
  this should be part of the cleanup plateform goal IMO.
 
  However I have a few questions:
 
   - How do we migrate user settings from gconf to dconf? If it is not
  done on GSettings/dconf level, that means that all applications will
  still have to link on libgconf to read old values and save them on new
  dconf keys at startup, and set a flag settings converted so that
  conversion is ran only once.
 
 Is there a need to convert user settings? I mean, we're talking about
 GNOME 3.0 here, most sensible data is stored via
 evolution-data-server, tracker, or other custom storage so the only
 difference would be appearance. I don't think that migration is an
 issue.
 
e-d-s stores the data in GConf, so it needs to be migrated indeed. Also,
even though the desktop-wide settings might be obsoleted
(/desktop/GNOME, for instance), apps still need their /apps/$app
configuration tree to be migrated, since they would probably keep using
the same conf entries

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

Re: Module proposal: dconf

[Rodrigo Moya]

On Wed, 2009-10-14 at 18:24 +0100, Ross Burton wrote:
 On Wed, 2009-10-14 at 19:17 +0200, Rodrigo Moya wrote:
  e-d-s stores the data in GConf, so it needs to be migrated indeed. Also,
  even though the desktop-wide settings might be obsoleted
  (/desktop/GNOME, for instance), apps still need their /apps/$app
  configuration tree to be migrated, since they would probably keep using
  the same conf entries
 
 Actually eds doesn't store anything in gconf, but it does read a few
 keys that Evolution stores there.  It's only the location of the files
 on disk, not real user data.
 
right, re-reading my mail I see the confusion.. of course I meant the
GConf keys for the ESource's, not the real user data, sorry for the
confusion

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

Re: Module proposal: dconf

[Rodrigo Moya]

On Tue, 2009-10-13 at 13:12 +0200, Vincent Untz wrote:
 Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
  El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
   Hello
   
   On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
 I'd like to propose the inclusion of dconf for GNOME 2.30 in the
 desktop release set.

No.
   
   Pretty please?
   
  
  No.
  
  Diego (who is not even an r-t member but wanted to be part of the fun)
 
 Heh :-)
 
 Ryan is a bit sad to not get feedback on his proposal, so a bit more
 seriously: I think what we probably need is a migration plan. Should we
 move all the code from gconf to dconf in one cycle (if possible)? Should
 apps implement migration for the data in gconf? etc.
 
I think it makes sense to do the migration for all the apps at once.
Also, the migration from gconf can be done directly from dconf, the
first time it starts, or even it could be clever enough to synchronize
changes from gconf every time it starts, to cover apps that migrate to
dconf later. That would remove the apps' responsibility to do the
migration, which would be a lot of code to have that in all
applications.

And yes, I support the move from gconf to dconf! :)

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

Re: Module proposal: dconf

[Rodrigo Moya]

On Tue, 2009-10-13 at 07:54 -0400, Sandy Armstrong wrote:
 On Tue, Oct 13, 2009 at 7:34 AM, Rodrigo Moya rodr...@gnome-db.org wrote:
  On Tue, 2009-10-13 at 13:12 +0200, Vincent Untz wrote:
  Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
   El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
Hello
   
On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
 Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
  I'd like to propose the inclusion of dconf for GNOME 2.30 in the
  desktop release set.

 No.
   
Pretty please?
   
  
   No.
  
   Diego (who is not even an r-t member but wanted to be part of the fun)
 
  Heh :-)
 
  Ryan is a bit sad to not get feedback on his proposal, so a bit more
  seriously: I think what we probably need is a migration plan. Should we
  move all the code from gconf to dconf in one cycle (if possible)? Should
  apps implement migration for the data in gconf? etc.
 
  I think it makes sense to do the migration for all the apps at once.
  Also, the migration from gconf can be done directly from dconf, the
  first time it starts, or even it could be clever enough to synchronize
  changes from gconf every time it starts, to cover apps that migrate to
  dconf later. That would remove the apps' responsibility to do the
  migration, which would be a lot of code to have that in all
  applications.
 
 I was thinking that too, given the time required for bindings to catch
 up for Mono and Python apps, but doing a migration from gconf on each
 login would cancel out one of the main benefits of dconf: improved
 performance at login (if I understand the wiki correctly).
 
well, change at login with at idle times, but I think it makes sense
to have dconf do the migration


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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Sat, 2009-10-03 at 17:02 +0200, Florian Ludwig wrote:
 Hi
 
 i dig a little into couchdb/desktop-couch and am wondering about
 security. Did I understand it right that desktop-couch starts couchdb on
 a random port without any password requirements, bound to 127.0.0.1?
 While not being attackable from the outside, still every program
 regardless which users runs it can read my contact list? Or did I got
 something wrong?
 
yes, you missed the OAuth authentication that is enabled by default in
desktopcouch. All couchdb HTTP requests need to be signed with the OAuth
signature. For remote servers, you can set it up also with OAuth, or
with simple username/password credentials


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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Fri, 2009-10-02 at 11:40 +0200, Mikkel Kamstrup Erlandsen wrote:
 
  no, shouldn't be a big task, as confirmed by the CouchDB developers this
  afternoon. The only thing that I'm not sure about is that they mentioned
  e4x
  (http://www.ecma-international.org/publications/standards/Ecma-357.htm )
  being needed in the JS implementation, so does libseed support that?
 
 Hm... I don't get why XML processing would be needed. All there is to
 it should be described here:
 http://wiki.apache.org/couchdb/View_server?action=showredirect=ViewServer
 
 Of course this means that all views should be written in a language
 supported by the ViewServer (that is, JS/libseed/webkit). Or maybe it
 is because they use some XML processing with JS internally - but I
 actually didn't think that the couch server would require libmozjs,
 only the external viewserver /usr/lib/couchdb/bin/couchjs?
 
right, but from a couchdb developer:

Many people consider e4x
(http://www.ecma-international.org/publications/standards/Ecma-357.htm)
to be a feature available in couchdb JS views

so, that's the reason, I guess people heavily use it for writing views?
Will get more information later

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Fri, 2009-10-02 at 16:07 +0200, Mikkel Kamstrup Erlandsen wrote:
 Is there some (semi) official place to discuss couchdb-glib by the
 way? I have some comments/questions, but I am not sure they are worth
 spamming desktop-devel with :-)
 
use the desktopcouch google group (soon to be moved somewhere else):

http://groups.google.com/group/desktop-couchdb

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

Re: Project Proposal: GNOME Innovation

[Rodrigo Moya]

On Wed, 2009-09-30 at 11:37 -0700, Sandy Armstrong wrote:
 On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote:
  The project is intended to use a Brainstorm System, which is already 
  provided by
  IdeaTorrent. It is already implemented in successful projects such as Ubuntu
  Brainstorm, SourceForge.net and others.
 
 Is there any data indicating that Ubuntu Brainstorm works better than
 filing enhancement bugs?  Are there any statistics about how many
 Ubuntu Brainstorm ideas are actually implemented, and how many are
 implemented largely due to feedback from Brainstorm?
 
AFAIK, brainstorm.ubuntu.com is used as the base (one of them, the other
being bug reports and already existing feature enhancement requests in
the bug tracker) for development of new Ubuntu releases. Popular ideas
are converted to blueprints (bugs in the GNOME case I guess), then
discussed during the UDS (Ubuntu Developer Summit) and assigned for the
next cycle.

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

Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

Hi

Purpose
===
couchdb-glib is a library to implement the protocol to talk to CouchDB
servers (http://couchdb.apache.org), a schema-free, json-based, database
of documents, which offers synchronization and replication between
several machines.

evolution-couchdb is the 1st module to make use of couchdb-glib, to
allow contacts from Evolution to be stored in CouchDB databases and
replicated/synchronized for free to other CouchDB servers.

Target
==
couchdb-glib for the developer platform
evolution-couchdb for the desktop

Dependencies

couchdb-glib depends on json-glib, libsoup, libuuid and (optionally)
libssl (for OAuth authentication)
evolution-couchdb depends on couchdb-glib, evolution-data-server and
evolution

Resource usage
==
Source code is already in GNOME's git (couchdb-glib and
evolution-couchdb modules)
Tarballs are already published on GNOME's FTP
Bugs are right now in Launchpad, but moving them to GNOME's bugzilla as
soon as needed

Adoption

Both modules are included in Ubuntu One service integration in Ubuntu
Karmic upcoming release, to provide contacts synchronization between the
desktop CouchDB database and the cloud-based services of Ubuntu One.

For GNOME 2.29, plans are to add support for calendars and tasks
(evolution), and, hopefully, also notes (Tomboy), metadata (tracker),
configuration settings (dconf, when adopted, if so)

GNOME-ness
==
Right now, everything is setup like any GNOME project, that is, it uses
gettext for translations, and should be accessible (almost no UI
involved right now, just a very simple settings widget for evolution to
setup CouchDB addressbooks).

It is not translated into any language though, but translators should be
able to start translating it straight away, since all its ready. Also,
couchdb-glib API documentation is missing, but that's one priority task
for the GNOME 2.29 cycle, whether the modules are accepted or not.

Bugs are in Launchpad, but could be moved to bugzilla.gnome.org pretty
easily for the bugsquad.

3.0 readiness
=
No deprecated libraries or symbols being used. Also, the addition of an
online services infrastructure could give 3.0 another major feature to
offer to users, apart from what is already planned.

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:48 +0200, Johannes Schmid wrote:
 Hi all!
 
 Maybe I get this wrong but wouldn't it be easier to access CouchDB from
 libgda database-wrapper that we already have in the external
 dependencies?
 
well, couchdb is not a relational database, in the sense that a CouchDB
database (what could be treated in libgda as a table) can contain
records with totally different fields, so it can't be easily mapped
1-1 to a relational table. For instance, for evolution-couchdb, we
have a single database for contacts, but there's nothing preventing
people from putting in that database records containing appointments, or
notes, or whatever.

We have though a special field for all records, called record_type (see
http://www.freedesktop.org/wiki/Specifications/desktopcouch ) which
specifies which type of record it is, so that could be used in libgda
to, for instance, map a CouchDB database to a table containing all
contacts. But again, what do you do with the other records, some of
which might not contain the record_type field?

Also, CouchDB offers some noSQL stuff, like adding attachments to JSON
documents, and has the notion of conflicting documents which you need to
resolve, so mapping that to a relational database might be a hard task.
And also, the couchdb-glib API is straightforward (give me the list of
dbs/documents, update this doc, etc), while making apps use libgda to
access it would be a hard thing to convince maintainers (believe me I
know, I've worked for many years in GNOME-DB, and tried to convince
people to use it :-). This is not to say that libgda is not useful, of
course it is, for applications accessing relational databases (or other
formats easily mapped to relational databases).

I like though the idea of writing a libgda CouchDB backend, but this
could only be mapped to databases containing records with the
record_type field, and with that record_type well documented.

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:52 +0200, Frederic Crozat wrote:
 Le jeudi 01 octobre 2009 à 13:42 +0200, Rodrigo Moya a écrit :
  Hi
  
  Purpose
  ===
  couchdb-glib is a library to implement the protocol to talk to CouchDB
  servers (http://couchdb.apache.org), a schema-free, json-based, database
  of documents, which offers synchronization and replication between
  several machines.
  
 
  For GNOME 2.29, plans are to add support for calendars and tasks
  (evolution), and, hopefully, also notes (Tomboy), metadata (tracker),
  configuration settings (dconf, when adopted, if so)
 
 Since I'm not familiar with CouchDB, does it requires a specific
 server-side software to handle synchronisation or does a plain Apache
 CouchDB server is enough ?
 
it just needs a CouchDB server instance running somewhere (locally, on a
remote server, etc), no Apache needed. It's an Apache project, but it
runs on its own, on its specific port.

So it's quite lightweight

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 12:55 +0100, John Carr wrote:
 Hi,
 
 On Thu, Oct 1, 2009 at 12:42 PM, Rodrigo Moya rodr...@gnome-db.org wrote:
  Hi
 
  Purpose
  ===
  couchdb-glib is a library to implement the protocol to talk to CouchDB
  servers (http://couchdb.apache.org), a schema-free, json-based, database
  of documents, which offers synchronization and replication between
  several machines.
 
  evolution-couchdb is the 1st module to make use of couchdb-glib, to
  allow contacts from Evolution to be stored in CouchDB databases and
  replicated/synchronized for free to other CouchDB servers.
 
  Target
  ==
  couchdb-glib for the developer platform
  evolution-couchdb for the desktop
 
  Dependencies
  
  couchdb-glib depends on json-glib, libsoup, libuuid and (optionally)
  libssl (for OAuth authentication)
  evolution-couchdb depends on couchdb-glib, evolution-data-server and
  evolution
 
 I've not looked at evo-couchdb, is the intention that there would be a
 local couchdb instance or that it would connect directly to a remote
 couchdb?
 
evo-couchdb can work with a per-user CouchDB
(https://edge.launchpad.net/desktopcouch ) which is what is used for
Ubuntu One syncing, with a system-wide CouchDB (http://localhost:5984)
or with any remote server you set up. On that server you just need to
run a CouchDB instance on a known port, and create an addressbook in
Evolution to point to it.

The Evolution-couchDB UI shows the 3 options just for the sake of
simplicity for the user, but all 3 options are the same, you just need
to point it to a URL:port, and evo-couchdb uses the same code to connect
to all 3 of them.

Of course, the most interesting thing is to be running a local CouchDB,
so that it can get synchronized to a remote server, but again,
evo-couchdb does not force any specific setup. Another typical setup, I
guess, would be to connect evolution to a couchdb server on your home
network, and synchronize that with a remote server on your
office/whatever. Evo-couchdb can deal with any setup you can think of

 If there is a local couchdb exepected for the common case then maybe
 the mozilla js dependency needs a mention.
 
it is not required for evo-couchdb to work, so I don't think it needs
any mention, apart from saying that if you want to run a local CouchDB,
you need to install CouchDB and all its dependencies.

  Resource usage
  ==
  Source code is already in GNOME's git (couchdb-glib and
  evolution-couchdb modules)
  Tarballs are already published on GNOME's FTP
  Bugs are right now in Launchpad, but moving them to GNOME's bugzilla as
  soon as needed
 
  Adoption
  
  Both modules are included in Ubuntu One service integration in Ubuntu
  Karmic upcoming release, to provide contacts synchronization between the
  desktop CouchDB database and the cloud-based services of Ubuntu One.
 
  For GNOME 2.29, plans are to add support for calendars and tasks
  (evolution), and, hopefully, also notes (Tomboy), metadata (tracker),
  configuration settings (dconf, when adopted, if so)
 
 
  GNOME-ness
  ==
  Right now, everything is setup like any GNOME project, that is, it uses
  gettext for translations, and should be accessible (almost no UI
  involved right now, just a very simple settings widget for evolution to
  setup CouchDB addressbooks).
 
  It is not translated into any language though, but translators should be
  able to start translating it straight away, since all its ready. Also,
  couchdb-glib API documentation is missing, but that's one priority task
  for the GNOME 2.29 cycle, whether the modules are accepted or not.
 
  Bugs are in Launchpad, but could be moved to bugzilla.gnome.org pretty
  easily for the bugsquad.
 
  3.0 readiness
  =
  No deprecated libraries or symbols being used. Also, the addition of an
  online services infrastructure could give 3.0 another major feature to
  offer to users, apart from what is already planned.
 
 Have you considered using the NEPOMUK ontologies (they've spent quite
 a lot of time developing ways of describing contacts and calendars and
 such things and from your ML it looks like you are reinventing the
 wheel).
 
I talked with you about it, and haven't had time this cycle to look much
at it, but yes, it might be interesting to look at using them, or at
least integrating easily with tracker's usage of them


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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 14:24 +0100, Ross Burton wrote:
 On Thu, 2009-10-01 at 14:12 +0200, Rodrigo Moya wrote:
   If there is a local couchdb exepected for the common case then maybe
   the mozilla js dependency needs a mention.
   
  it is not required for evo-couchdb to work, so I don't think it needs
  any mention, apart from saying that if you want to run a local
  CouchDB,
  you need to install CouchDB and all its dependencies. 
 
 Do you expect anyone to run it against a remote server?  If connected to
 a remote server does evo-couchdb support offline operation and replaying
 of offline events, or does it fail if you are offline?
 
it would fail if you're offline, yes. But we could easily add a cache of
offline operations, and sync that to the server when back online.

 I always thought the entire point was that you ran a local couchdb
 server so that you could then sync with other servers in the cloud.
 Sure, you can run it against a remote server, but how much will that be
 used?
 
right, but local couchdb server can be on your home network, for
instance, no need for it to be on the cloud. Your home server could then
just sync with the cloud.

But yes, the best scenario is to have a couchdb instance on your
machine, and sync that to whatever remote machines you want.

  So it's quite lightweight
 
 $ sudo aptitude install couchdb
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Reading extended state information  
 Initializing package states... Done
 The following NEW packages will be installed:
   couchdb erlang-asn1{a} erlang-base{a} erlang-corba{a} erlang-crypto{a} 
 erlang-docbuilder{a} 
   erlang-edoc{a} erlang-eunit{a} erlang-ic{a} erlang-inets{a} 
 erlang-inviso{a} erlang-mnesia{a} 
   erlang-nox{a} erlang-odbc{a} erlang-os-mon{a} erlang-parsetools{a} 
 erlang-percept{a} 
   erlang-public-key{a} erlang-runtime-tools{a} erlang-snmp{a} erlang-ssh{a} 
 erlang-ssl{a} 
   erlang-syntax-tools{a} erlang-tools{a} erlang-webtool{a} erlang-xmerl{a} 
 libsctp1{a} lksctp-tools{a} 
 0 packages upgraded, 28 newly installed, 0 to remove and 7 not upgraded.
 Need to get 20.2MB of archives. After unpacking 35.6MB will be used.
 Do you want to continue? [Y/n/?] 
 
 CouchDB on Debian takes up 35MB of disk space.  Not exactly lightweight.
 
right, this is because of lots of unneeded erlang dependencies. On
Ubuntu Karmic the dependencies have been reviewed (for inclusion on the
main CD), and I think it's just 14MB now (not sure about the exact
numbers, but can check if you want)

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
 
  it is not required for evo-couchdb to work, so I don't think it needs
  any mention, apart from saying that if you want to run a local CouchDB,
  you need to install CouchDB and all its dependencies.
 
 I only brought it up because of the ongoing mozilla vs webkit
 discussions (and mozilla js vs seed/jscore) and i think the most
 useful configuration of evo-couchdb does depend on couchdb and hence
 mozilla js.
 
 I'm only so bothered in as much as i really don't want a desktop in
 the future to need 2 javascript engines and each application depending
 on 2 or 3 different database engines and so on :]
 
you are indeed right, but I see couchdb can use different javascript
libraries (it has a configure option to tell it where to find libjs) so
I guess we could ask the couchdb guys to support our JS engine (when we
decide which one to use :)

 
  Have you considered using the NEPOMUK ontologies (they've spent quite
  a lot of time developing ways of describing contacts and calendars and
  such things and from your ML it looks like you are reinventing the
  wheel).
 
  I talked with you about it, and haven't had time this cycle to look much
  at it, but yes, it might be interesting to look at using them, or at
  least integrating easily with tracker's usage of them
 
 I know the feeling. We should really sit down and look at this before
 your home grown ontologies are frozen, though. Will you or sil be at
 GNOME Boston?

I'm not going, and seems sil is neither.

But we probably could have some IRC meeting with the tracker, couchdb
guys and anyone interested?

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:
 On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
  
   it is not required for evo-couchdb to work, so I don't think it needs
   any mention, apart from saying that if you want to run a local CouchDB,
   you need to install CouchDB and all its dependencies.
  
  I only brought it up because of the ongoing mozilla vs webkit
  discussions (and mozilla js vs seed/jscore) and i think the most
  useful configuration of evo-couchdb does depend on couchdb and hence
  mozilla js.
  
  I'm only so bothered in as much as i really don't want a desktop in
  the future to need 2 javascript engines and each application depending
  on 2 or 3 different database engines and so on :]
  
 you are indeed right, but I see couchdb can use different javascript
 libraries (it has a configure option to tell it where to find libjs) so
 I guess we could ask the couchdb guys to support our JS engine (when we
 decide which one to use :)
 
ok, just asked the couchdb devels about this, and it seems to be much
easier than I thought, so this should be easy to fix when we decide
which JS engine to use.

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

Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

On Thu, 2009-10-01 at 20:03 +0200, Mikkel Kamstrup Erlandsen wrote:
 2009/10/1 Rodrigo Moya rodr...@gnome-db.org:
  On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:
  On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
   
it is not required for evo-couchdb to work, so I don't think it needs
any mention, apart from saying that if you want to run a local CouchDB,
you need to install CouchDB and all its dependencies.
  
   I only brought it up because of the ongoing mozilla vs webkit
   discussions (and mozilla js vs seed/jscore) and i think the most
   useful configuration of evo-couchdb does depend on couchdb and hence
   mozilla js.
  
   I'm only so bothered in as much as i really don't want a desktop in
   the future to need 2 javascript engines and each application depending
   on 2 or 3 different database engines and so on :]
  
  you are indeed right, but I see couchdb can use different javascript
  libraries (it has a configure option to tell it where to find libjs) so
  I guess we could ask the couchdb guys to support our JS engine (when we
  decide which one to use :)
 
  ok, just asked the couchdb devels about this, and it seems to be much
  easier than I thought, so this should be easy to fix when we decide
  which JS engine to use.
 
 Indeed, one can use any language as a CouchDB indexer. Indexer -
 because that is really what the Javascript is used for. The (very)
 simplified explanation is that you can't do custom queries against
 Couch only index lookups, but you can create some very funky indexes.
 These indexes are generated by calling out to an outside process over
 a socket using some protocol defined in the Couch docs (which is also
 why Couch is still very fast, the script engine is only used on
 indexing time).
 
 This external indexer process use libmozjs by default but you can
 create your custom indexer in what ever language you want; Python,
 Perl, even C if you are adventurous. It should not be a big task to
 write an indexer based on libseed I think - although I haven't checked
 the details.
 
no, shouldn't be a big task, as confirmed by the CouchDB developers this
afternoon. The only thing that I'm not sure about is that they mentioned
e4x
(http://www.ecma-international.org/publications/standards/Ecma-357.htm )
being needed in the JS implementation, so does libseed support that?


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

social services as a desktop service?

[Rodrigo Moya]

Hi

During the development of Ubuntu Karmic, I discussed with some people
about having social services accounts (facebook, twitter, etc)
configured in one place, about-me specifically. Since it was a bit late
for GNOME 2.28, I postponed the discussion, but now that 2.28.0 is
almost out, I'd like to start it here.

So, the idea is to have a central place where all those accounts are
configured, so that applications using those services (gwibber for now,
not sure if there are some others?) can just use that instead of having
to ask the user in every application his/her credentials for those
social services.

So, there are several things to discuss:

* is about-me the correct place for this?

* should we only provide configuration of social service accounts, or
does it make sense to have all web services accounts configured there
(social services + flickr + last.fm + IRC + IM + mail + etc etc)?

* should about-me (or wherever the code lands) just provide the accounts
configuration, or should it also provide access to their protocols (of
course, via a separate (dbus) service) so that any app can just use that
instead of implementing the protocol itself? I guess the protocol's
implementations can live in different places, like Empathy for IM, e-d-s
for mail, calendaring, and others, not just in one place, but at least
should there be an easy way for apps to access any of them?

anything else?

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

Re: Tracker, Zeitgeist, Couchdb...where is the problem ?

[Rodrigo Moya]

On Tue, 2009-08-18 at 18:38 -0400, Jamie McCracken wrote:
 On Wed, 2009-08-19 at 00:27 +0200, Rodrigo Moya wrote:
  On Tue, 2009-08-18 at 16:48 -0400, Matthias Clasen wrote:
   I think this recent discussion about tracker as a gnome module is
   somewhat backwards. I don't think it is leading us anywhere to talk
   about ontologies and rdf and events and timelines and metadata stores
   and kernel apis before we answer the first question:
   
   What is the user problem that we are solving here ?
   Can that be described in a paragraph ?
   And if it can, is it something that a 'regular' user would recognize
   as a problem he has on his computer ?
   
   Once we have the problem scoped out, we need to look at the user
   experience we want to aim for in solving it. Will it be a single
   search-for-everything dialog ? A query language ? Tagging everywhere ?
   
   After that, it might be possible to evaluate whether tracker,
   zeitgeist, couchdb or something else can be part of the
   implementation...
   
  couchdb provides just the storage of any kind of data, no indexing,
  searching, etc, so I think they solve different problems. In fact,
  tracker could just use local files as storage or a couchdb database. If
  using couchdb, it would get replication and synchronization for free,
  but it would still provide the indexing
 
 
 For your interest, I did want to use CouchDb for our backup of user
 metadata in tracker precisely for that reason. Currently we use turtle
 files which is not optimal. 
 
 However I suspect CouchDb is big and probably too big a dependency for
 nokia's smaller devices so it might not happen or would have to be
 optional in tracker.

yes, it might be too big. At canonical, for ubuntu karmic, we have
reduced the dependencies (erlang runtime) to the minimum (5-6 MB IIRC),
which is ok for a desktop machine, but I guess it's still too big for
nokia's smaller devices?

And of course, couchdb should always be optional. It makes sense to use
it as a storage for sharing data between applications (evolution and
akonadi are both using it to store contacts, which gives us shared data
storage for both GNOME and KDE users. ditto for firefox/epiphany for
bookmarks, evo/tomboy for notes, etc, etc), but the big point about it
is to allow replication of the data to other machines, which might not
be what some users want. So yeah, should still be optional

In fact, I see the tracker integration, if it happens in a GNOME-wide
aspect, like this: applications use tracker to store data, and there is
a global setting to allow users to specify where to store data, locally,
or on couchdb, which would give the replication/synchronization feature,
without changing any application, which would still use tracker to store
their data.

  I dont know a great deal about CouchDb but feel
 free to sell it to Nokia if you can :)
 
well, I'm a simple developer, I'll let the selling to the sales
people :D Although technically it would make a lot of sense, since data
saved in the nokia devices would get replicated to whatever couchdb
remote instance the user has, and appear automatically on the user's
desktop, without having to synchonize by hand the nokia device with the
PC. I think that's a good way to sell it to Nokia :D


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

Re: Tracker, Zeitgeist, Couchdb...where is the problem ?

[Rodrigo Moya]

On Wed, 2009-08-19 at 00:36 +0200, Philip Van Hoof wrote:
 
 We evaluated CouchDB as a primary store over sqlite, but CouchDB lacked
 *very* important features. This makes it undoable. Feel free to get in
 touch with us to discuss which precise features I mean.
 
I talked to some tracker people at GCDS about it, so I think I know what you're
talking about, and indeed the CouchDB guys are aware of that (one of
them was at GCDS), and since some of those features are demanded by many
couchdb users (outside of the desktop also), I think they will be added
sooner or later.


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

Re: New module proposal: tracker

[Rodrigo Moya]

On Tue, 2009-08-18 at 21:21 +0200, Lennart Poettering wrote:
 On Tue, 18.08.09 21:09, Patryk Zawadzki (pat...@pld-linux.org) wrote:
 
  
  On Tue, Aug 18, 2009 at 8:57 PM, Lennart Poetteringmzta...@0pointer.de 
  wrote:
   (I don't want to create the impression that I am opposed to the idea
   of a desktop search engine. I actually do believe it makes sense, but
   really, you need to do a better job selling the specific technology
   tracker does.)
  
  Don't think of the RDF store as Google where you enter two words and
  get back top 10 results. Think of it as a database that has all kinds
  of weird relations for different objects. You could ask it for the
  last.fm track that was playing while you were looking at lolcat images
  on the second day od GCDS while chatting with people whose last name
  contained a lowercase n :)
  
  More real life examples:
  
  - show me all the party pics
  - give me files and data related to gnome bug #123
  - list all the files I received from Lennart during the last week
  (over Jabber, e-mail etc.)
 
 Nice idea, but is this even realistic? How's a UI for this supposed to
 look like? I mean, Google is so awesome because you type stuff in a
 text field with only a minimal syntax requirements and will spit out
 useful stuff.
 
 But how would you expose in the UI a search mask that allows you to
 formulate queries like give me files and data related to gnome bug
 #123? Are you planning to duplicate the bugzilla search form in the
 GNOME Search interface? If that's the case, then www, stop right
 there!
 
Nat's dashboard could make sense for this, where you have related items
to the stuff you're doing, like when you're writing a mail to Lennart,
see all IM logs, mails, commits, etc related to that?

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

Re: New module proposal: tracker

[Rodrigo Moya]

On Tue, 2009-08-18 at 18:16 +0200, Maciej Piechotka wrote:
 On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:
  Hi all,
  
  So we recently polled the tracker mailing list to make sure the core 
  developers and others interested had an opinion on GNOME module 
  inclusion for Tracker. You can see the thread here:
  
  http://mail.gnome.org/archives/tracker-list/2009-August/msg7.html
  
  The response was positive. So I would like to propose Tracker as a new 
  GNOME module.
  
  Right now Tracker 0.7 is currently in development and we are hoping to 
  get the 0.7. unstable release out the door in the coming month or so.
  
  Right now we are considering making the miners (the file system crawling 
  at this point) optional so it acts purely as a store if needed by ISVs. 
  This is not yet done in master but can be if that's a GNOME requirement.
  
  Dependencies include:
  
 libxml = 0.6
 libpng = 1.2
 libuuid
 zlib
 dbus = 0.60
 sqlite3 = 3.5 (built with --enable-load-extension)
 hal = 0.5
 vala = 0.7.3
 pango = 1.0.0
  
  Beyond that, the rest of the requirements affect your extraction 
  ability. For example, if poppler-glib is on the platform, you can then 
  extract PDF files. This also depends on if streamanalyser is used or not 
  (which does all extraction for us and negates the needs for specific 
  libraries in Tracker).
  
  Dependencies about to be dropped but still needed:
  
 gmime
 lex
 yacc
 libraptor
  
  The git repository is here:
  
  http://git.gnome.org/cgit/tracker/
  
  We import the following libraries:
  
 libinotify
 rasqal
  
  Licensing wise, those libinotify and rasqal both share the LGPL, as does 
  libtracker. The rest is GPLv2 or later.
  
  /discuss ;)
  
 
 Well. Currently there are two projects which, at least for the first
 sight, are similar - Tracker and Beagle. So the first question is why
 should Gnome include Tracker and not Beagle?
 
I might be wrong and things might have changed, but isn't beagle
unmaintained?


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

Re: Tracker, Zeitgeist, Couchdb...where is the problem ?

[Rodrigo Moya]

On Tue, 2009-08-18 at 23:02 +0200, Patryk Zawadzki wrote:
 On Tue, Aug 18, 2009 at 10:48 PM, Matthias
 Clasenmatthias.cla...@gmail.com wrote:
  I think this recent discussion about tracker as a gnome module is
  somewhat backwards. I don't think it is leading us anywhere to talk
  about ontologies and rdf and events and timelines and metadata stores
  and kernel apis before we answer the first question:
 
  What is the user problem that we are solving here ?
  Can that be described in a paragraph ?
  And if it can, is it something that a 'regular' user would recognize
  as a problem he has on his computer ?
 
 How about:
 
 Zeitgeist - provide means to find previously accessed data.
 
 Tracker - provide a well-defined (not just name=value strings but
 something close to an actual RDBMS) schema and service so desktop apps
 can provide context for the data they present (where did I get that
 file from?, is it related to any other files?, what other John Doe
 tracks do I have?).
 
 CouchDB - I have no idea why a desktop might need that.
 
it provides storage locally that can be automatically replicated to many
servers, so it is indeed very useful for desktop applications to provide
synchronization and replication of data to many computers. In fact, I am
thinking about proposing couchdb-glib and evolution-couchdb for
GNOME :-D


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

Re: Tracker, Zeitgeist, Couchdb...where is the problem ?

[Rodrigo Moya]

On Tue, 2009-08-18 at 23:18 +0200, Maciej Piechotka wrote:
 
 CouchDB: I don't really think it is needed. I'm not convinced - how many
 times do I need to change email client. Without proper definition of
 storage (such as FirstName vs. firstName vs ...) it won't help

we are defining the storage format (WIP still, but going on):

http://www.freedesktop.org/wiki/Specifications/desktopcouch

suggestions for improvement are more than welcome

  and the
 proper definition can be made w/out introducing networking (TCP/IP as
 IPC is not nice hack IMHO unless you want RPC).
 
it is indeed not ideal, and when implementing couchdb-glib (glib-based
API to talk to CouchDB databases, in case it wasn't clear from its
name :) I thought about providing a DBus API on top of the HTTP layer,
but it looked to me too many layers. Also, think that HTTP is used not
only locally, it is the same protocol to talk to both local and remote
databases, which is why HTTP is the chosen protocol.

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

Re: GNOME Menus restructuring

[Rodrigo Moya]

On Tue, 2009-07-28 at 13:04 -0400, Matthias Clasen wrote:
 We have done essentially this (with the extra Preferences menu in
 between) for a few releases in Fedora, and we have gone back to using
 a single Preferences menu by default now. The two main problems we
 faced with this are
 
 1) deep menus are hard (your approach kinda avoids this by nuking Preferences)
 
 2) The categories are not clear enough to find what you are looking
 for without constantly strolling through several submenus.
 
 I don't think any amount of reorganization will make the menus really
 good. A menu system is just not a good fit for this amount of data
 that is not very strictly categorized.
 
 I'd rather see us focus on moving away from these menus via
 gnome-shell and  and new control-center shell.
 
 
I think all those menus could perfectly be replaced by a 'Control
Center' menu item, and then have the control center shell provide an
easy way to search for stuff


-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME Menus restructuring

[Rodrigo Moya]

On Wed, 2009-07-29 at 13:31 +0400, Alexey Rusakov wrote:
 В Срд, 29/07/2009 в 11:18 +0200, Rodrigo Moya пишет: 
  On Tue, 2009-07-28 at 13:04 -0400, Matthias Clasen wrote:
   We have done essentially this (with the extra Preferences menu in
   between) for a few releases in Fedora, and we have gone back to using
   a single Preferences menu by default now. The two main problems we
   faced with this are
   
   1) deep menus are hard (your approach kinda avoids this by nuking 
   Preferences)
   
   2) The categories are not clear enough to find what you are looking
   for without constantly strolling through several submenus.
   
   I don't think any amount of reorganization will make the menus really
   good. A menu system is just not a good fit for this amount of data
   that is not very strictly categorized.
   
   I'd rather see us focus on moving away from these menus via
   gnome-shell and  and new control-center shell.
   
  I think all those menus could perfectly be replaced by a 'Control
  Center' menu item, and then have the control center shell provide an
  easy way to search for stuff
 Control Center as it is now takes even more of screen estate; besides it
 is a separate application, so the action that is now two-click for me
 (open the menu; find and activate the necessary item) becomes
 three-click (open the menu; run Control Center, another window opens;
 find and activate the necessary item). Moreover, the task termination
 sequence from one-click (close the settings window) becomes two-click
 (close the settings window; close the Control Center window). Don't see
 how a user wins in this approach.
 
well, that's if you know which tool you need to start. But when looking
for stuff, it becomes much more than 2-clicks, since you'll need to
click a menu item, a window opens, look for stuff on that window, close
it, and repeat again until you find what you're looking for.

If the control center capplets provide a list of keywords in
their .desktop file, searching for 'mouse cursor' on the control center
shell search would show the correct tool that the user needs to start.

I think something like that is a big win for most users, if done right

-- 
Rodrigo Moya rodr...@gnome-db.org

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

gnome-control-center branched for 2.26

[Rodrigo Moya]

As $SUBJECT says, we now have a gnome-2-26 branch for 2.26 further
development for gnome-control-center
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: Platform

[Rodrigo Moya]

On Tue, 2009-05-05 at 14:36 -0500, Shaun McCance wrote:
 
 Good catch on libcanberra.  It's clearly good for us
 to have a convenient API for this.  Do we really want
 to push another micro-library for that?  Should GTK+
 just learn to do it?
 
yeah, in fact, libcanberra provides a libcanberra-gtk lib which could be
part of GTK. libcanberra itself, I guess, would need to keep as a
separate lib for KDE and others to use it (if they do or plan to, which
I'm not sure about)
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: dconf

[Rodrigo Moya]

On Tue, 2009-04-07 at 10:23 -0400, Ryan Lortie wrote:
 Callum McKenzie wrote:
  Can current gconf settings be easily loaded into dconf? e.g. can someone
  launching into a gnome 3.0, dconf-based, system for the first time still
  have the same wallpaper settings as they did before?
  
  I'm assuming that a) the settings still make sense and b) that the
  application can provide a mapping between old and new settings.
 
 Yes, but currently this would have to be completely manual and would 
 require the application to link to both dconf and GConf.  This sucks.
 
 I guess a good solution would be to provide some easy-to-use framework 
 by which applications could have migration scripts in python or 
 something.  That way the application itself doesn't need to do GConf, 
 but the python script can if GConf is still installed.
 
 Ideas are definitely welcome in this direction.
 
there could be a process started by gnome-shell that just migrates the
whole GConf database to dconf? or is this automatic migration not
possible?
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME 2.26 module inclusion discussion heats up

[Rodrigo Moya]

On Fri, 2009-01-16 at 10:55 -0500, Matthias Clasen wrote:
 On Fri, Jan 16, 2009 at 8:27 AM, Rodrigo Moya rodr...@gnome-db.org wrote:
 
  yeah, I agree with you, I think both should be the same (an applet or an
  icon), so since we already have the applet, I guess it would make sense
  to add code to the applet to hide itself and start the notification icon
  if PA is running, or something like that
 
 But this is not a runtime decision. Either your distro is using
 pulseaudio (and it should), then you always want the new icon,
 or it isn't, and then you need something else. If you are using
 pulseaudio, you don't want to have an invisible mixer applet on your
 panel, eating resources and possibly causing other unwanted side
 effects.

you're right about the resources taken by the hidden applet, but as you
see, Debian, openSUSE and Mandriva need ways to offer users a fallback,
so we really need it. If there's a better solution than hiding the
applet, let's use that, but can't think of a better (and quicker) way
right now
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME 2.26 module inclusion discussion heats up

[Rodrigo Moya]

On Fri, 2009-01-16 at 17:35 +0100, Lennart Poettering wrote:
 On Fri, 16.01.09 17:12, Josselin Mouette (j...@debian.org) wrote:
 
  Le vendredi 16 janvier 2009 à 10:55 -0500, Matthias Clasen a écrit :
   But this is not a runtime decision. Either your distro is using
   pulseaudio (and it should)
  
  Again, this cannot be a distribution choice!
  
  We can ship PA by default and make everything possible to get the best
  of it, but breaking systems where it is not installed is not an option,
  given the number of setups that don’t work with it.
 
 Hmm. Somehow I get the feeling that the only distribution where this
 really matters is Debian -- because you guys want to ship all and
 everything and leave the user the decision what he uses and what he
 doesn't. (I mean, you guys even include OSS4!) The other distributions
 do an informed decision whether they want to adopt PA or not and then
 integrate it fully or not. 
 
not only Debian, in openSUSE we had to add a way to disable PA (which is
used by default) because some users were complaining about PA not
working on their setups. For those users, we really need to offer them a
solution, it's not only about choosing to use it or not, it is that in
some setups it seems to not work as some users want it to. 

-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME 2.26 module inclusion discussion heats up

[Rodrigo Moya]

On Thu, 2009-01-15 at 13:22 +0100, Josselin Mouette wrote:
 Le jeudi 15 janvier 2009 à 12:55 +0100, Rodrigo Moya a écrit :
   If the two applets don’t share the basic UI (one panel applet and one
   notification icon), that’s a bigger problem. I guess we could always
   ship the GStreamer one and start the PA one only if PA is running, but
   that’s not very consistent.
   
  you're right here, we need some sort of run-time activation of one
  applet or the other. I guess gnome-settings-daemon's sound module could
  add the applet or the notification icon depending on PA/not PA.
 
 The problem is not about being able to start the applet, which is at
 worst a job of encapsulating it in a script. The problem is about having
 the same basic UI in both cases.
 
 For example, if you notice PA doesn’t work for you and disable it, you
 will stop seeing the notification icon when logging in again. However
 the GStreamer applet will not be started, since its startup mechanism is
 very different and depends on the panel configuration.
 
 OTOH, if during an upgrade the default changes to being PA, there will
 suddenly be two mixer controls on the panel.
 
 Hence the need for some homogenization. Given the various concerns that
 have been raised about misusing the notification area, I think we should
 re-focus on the applet idea.
 
yeah, I agree with you, I think both should be the same (an applet or an
icon), so since we already have the applet, I guess it would make sense
to add code to the applet to hide itself and start the notification icon
if PA is running, or something like that
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME 2.26 module inclusion discussion heats up

[Rodrigo Moya]

On Tue, 2009-01-13 at 09:47 +0100, Josselin Mouette wrote:
 Le lundi 12 janvier 2009 à 20:54 +0100, Lennart Poettering a écrit :
   Oh right, so we have to choose between supporting only PA and screw
   other users, or not benefit from PA at all. What a choice.
  
  Uh? You can ship both if you wish and pass the decision what to use to
  the user. I mean, that is the usual way Debian solves problems like
  this, isn't it?
 
 No, that’s not the “usual way”. Having two identical applications in the
 menu is not the “usual way”. But as I have already explained, we can
 deal with it using a hack, so please forget about that. Just go on
 shipping the two mixers, and let’s stop this pointless discussion.
 
well, I guess we can easily have a gnome-volume-control script that
starts the PA one or the GST one depending on user's choice, right? No
need for 2 entries in the menu

 
   How about the applet then? Is there a plan to bring back a gst-based
   one?
  
  Dunno. If you insist it could probably be kept around, but that's not
  up to me to decide.
 
 If the two applets don’t share the basic UI (one panel applet and one
 notification icon), that’s a bigger problem. I guess we could always
 ship the GStreamer one and start the PA one only if PA is running, but
 that’s not very consistent.
 
you're right here, we need some sort of run-time activation of one
applet or the other. I guess gnome-settings-daemon's sound module could
add the applet or the notification icon depending on PA/not PA.
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: new module proposal: notification-daemon+libnotify

[Rodrigo Moya]

On Fri, 2008-11-07 at 13:09 +, Calum Benson wrote:
 On 6 Nov 2008, at 17:38, David Zeuthen wrote:
 
  But not all notifications comes from applications launched by the  
  user.
  For example
 
  There is a high probability that one or more of your hard disk will
   malfunction within the next 24 hours
 
  Your laptop battery is being recalled
 
  Security updates available
 
  I'm not sure where we'd display stuff like this except for using icons
  in the notification area.
 
 Some sort of status icon change with an appropriate tooltip would  
 probably be sufficient for things that don't need immediate  
 attention.  For things that do, or for which there is no status icon,  
 an alert box is often more appropriate anyway.
 
wasn't libnotify/notification-daemon created to replace alert boxes? I
tend to find them quite useless, since I miss them most of the time
while typing without looking at the screen, so I don't think they are a
good solution for immediate attention stuff
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: new module proposal: notification-daemon+libnotify

[Rodrigo Moya]

On Mon, 2008-11-10 at 09:37 -0500, Matthias Clasen wrote:
 On Mon, Nov 10, 2008 at 9:11 AM, Martin Meyer [EMAIL PROTECTED] wrote:
  I sometimes miss my notifications too.. Would it be possible to
  remember notifications that have come through until they are
  explicitly acknowledged? We could bind some key to doing this, so that
  you press that key when the notification is showing to acknowledge it.
  For missed notifications, we could leave an icon in the notification
  area. When you click that icon it might show you all the
  unacknowledged notifications until clicked again. You'd probably need
  some button on all the notices to mark them as acknowledged.
 
 
 Some ideas for better handling of notifications can be found here:
 http://live.gnome.org/AlternativeNotificationsUI

it looks nice, but where would immediate-action-required notifications
be shown? Things like 'your battery is about to die'?
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Proposed module: project hamster

[Rodrigo Moya]

On Mon, 2008-07-28 at 14:16 +0200, Frederic Peters wrote:
 Vincent Untz wrote:
 
  Project Hamster is a nifty time tracking applet for the Gnome desktop.
  It helps to keep track on how much time has been spent during the day on
  set up activities.
 
 It is nifty, but I don't think it is useful for most people; and I
 don't want the GNOME desktop to become a collection of all the cool
 apps that are on gnomefiles.org (or the Internet, FWIW).
 
 So -1 for me, as I don't see any advantage in Project Hamster being
 adopted as an official module of the GNOME desktop.
 
while I agree about not having all the cool little apps in GNOME, I
think this can be useful to lots of people, so it would be ok IMO if it
were part of gnome-applets.
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Proposed module: project hamster

[Rodrigo Moya]

On Mon, 2008-07-28 at 09:40 -0700, Luis Villa wrote:
 On Mon, Jul 28, 2008 at 9:36 AM, Dave Neary [EMAIL PROTECTED] wrote:
  motivating reason for rejection, also... most of the apps we ship are
  mostly useless to most of our users.
 
  Do you think so ?  It may be I almost perfectly matched GNOME apps
  till today :)
 
  Looking in Utilities: I rarely use Calculator, Character map, or Disk
  Usage Analyser. You don't see me advocating they be dropped :)
 
 I'll go ahead and advocate dropping them, if it'll help ;)
 
 This is exactly the kind of app that makes me think we should have
 certification for non-core applications- a way to say 'this is great
 and useful and GNOME-y' (which it is) without saying 'this a part of
 the core of GNOME which is tied to our release cycle and QA
 standards.'
 
that would probably be fixed if we had the Desktop release splitted into
core (panel/applets, nautilus, control center, metacity, ...) and
applications
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: gnome-session proposal

[Rodrigo Moya]

On Thu, 2008-06-26 at 12:41 +1200, Callum McKenzie wrote:
 On Thu, June 26, 2008 11:07 am, William Jon McCann wrote:
 
  I don't think these are sufficient reasons to continue to solely rely
  on XSMP.  We can do these very well using D-Bus.
 
 Can I assume from your use of the word solely that your
 backwards-compatibility strategy is to leave XSMP support in place for
 legacy applications?
 
yeah, that's the only problem I see with William's suggestion. KDE
applications are still using XSMP AFAIK, so we'll need to support it in
some way
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: gnome-session proposal

[Rodrigo Moya]

On Thu, 2008-06-26 at 12:40 -0400, David Zeuthen wrote:
 On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
  KDE applications are still using XSMP AFAIK, so we'll need to support
  it in some way
 
 We do? What happens if we decide not to?
 
well, we'll get tons of bug reports about KDE apps run on GNOME not
being saved to the session :-)

of course, instead of supporting XSMP, we could try to get KDE use
William's new implementation
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Need Leadership

[Rodrigo Moya]

On Tue, 2008-06-24 at 12:27 +0300, natan yellin wrote:
 1. Host an annual developer awards contest. Apple does it, and there's
 really no reason why we shouldn't as well. The system would have to be
 adapted a bit, but it _is_ doable. Like it or not, shiny prizes and
 recognition help attract developers.
 
this sounds good to me, if the Foundation has money, we could have every
year a contest for the coolest GNOME project of the year. GSoC gets us
new developers mainly because of the prizes, so it is a good idea I
think to have something similar
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Future of GNOME: Semantics

[Rodrigo Moya]

On Sun, 2008-06-15 at 12:21 +1000, Michael Gratton wrote:
 Another example would be desktop-wide searching. A front-end search tool
 would be able to scan the session bus for objects supporting this
 interface and query each in turn for applicable results, presenting them
 as such - 10 matching emails in Evolution, 20 matching notes in Tomboy
 etc. This would mean that the existing engines (Tracker, Beagle)
 wouldn't need to write duplicate indexers for every application like
 Evolution, they can concentrate on the file system and full-text
 indexing. It also cuts down on data duplication - there isn't a copy of
 my email metadata in both Evo and Tracker and so it never needs to get
 crawled and cannot get out of sync.
 
this sounds quite good to deal with the 'too much disk space taken by
search engines', which indeed is too much (over 3GB here) if your home
is big
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: GNOME Showstopper Review

[Rodrigo Moya]

On Tue, 2008-06-17 at 14:13 +0200, Vincent Untz wrote:

  http://bugzilla.gnome.org/show_bug.cgi?id=515948
  clock window not shown if e-d-s has not authenticated to google calendar
  If a google calendar exists in Evolution and one clicks on the time in
  the clock applet, it hangs because google calendar is not available
  unless evo authenticates it. Very annoying, no patch available yet.
  In general, Google calendar support in Evolution is quite buggy and
  there are several bug reports dealing with issues.
 
 There are two things here:
 
  + the clock applet opens the calendar in a synchronous way. I'm afraid
the change is quite intrusive, which makes me think it won't go in
2.22.
  + authentication: I thought the clock applet handled calendar
authentication, but maybe I'm misremembering. Or maybe the google
backend needs something different? Does anybody know?
 
AFAIK, it doesn't handle authentication. It needs to be done (IIRC from
my evolution times) via the e-d-s API, and last time I tested, it stil
didn't handle it
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

gnome-settings-daemon and gnome-control-center branched for 2.22

[Rodrigo Moya]

Both gnome-settings-daemon and gnome-control-center have a new branch
gnome-2-22 for further 2.22.x development.
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Recommended/minimum versions for some fd.o external deps -- updates

[Rodrigo Moya]

On Thu, 2008-01-31 at 17:51 +0100, Luca Ferretti wrote:
 ...

also, what about iso-codes? jhbuild seems to be using 0.53, but latest
is 1.8. Is there any reason to use such an old version
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: build systems

[Rodrigo Moya]

On Fri, 2007-11-09 at 12:27 +0100, daniel g. siegel wrote:
 hello!
 
 i will begin this mail with a warning:
 **
 this topic is highly dangerous, it could result in flame-wars,
 holy-wars, suicide, death or murdering. so please be kind and nobody
 will get hurt (even not your cat or your hamster) and vincent may gets
 an ice cream ;)
 **
 
 now, as some of you know, cheese uses toc2 as build system. why? will
 some of you ask, he could have used autofoo too! well, it wasnt just i
 dont like autofoo and therefore.., the whole decision was made in
 several weeks and i really tried autofoo (and got about 7 patches, which
 autofoo'd cheese). i want to tell you what kept me off from autotools:
 
 it always takes three steps
 ===
 most projects in the unix world, who have compiled a package by themself
 know that three-step ./configure  make  make install. and in my
 opinion i really like it, its simple and gives (at least it should) you
 enough options to install it how and where you want. this is fine, but
 there are some cases, where this drove me crazy. do i really want to
 look through a 1000-lines Makefile and edit my things there, thats just
 far to complicate as it really doesnt have any structure. editing
 Makefile.in or configure.ac directly? see next point
 
you should be editing Makefile.am not Makefile.in, that's why you got
fed up of autofoo :-)

...

I think there are just very few people that love autofoo
inconditionally, but it has some features that, from what you say about
toc2, make it necessary, like building in all Linux flavors, for
instance.

When we have something prettier than autofoo that supports everything
that autofoo does, I wouldn't mind changing
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Input devices capplets

[Rodrigo Moya]

On Tue, 2007-11-06 at 17:02 +, Sergey Udaltsov wrote:
  About the many tabs: at least the Layouts tab could move to the i18n
  capplet when we have finished it.
 
 Oh really? But what about the Layout Options popup? It does not really
 belong to i18n...
 
how so? it belong to the layout part, which is in the localization
capplet mockup Denis sent a while ago, and which I should be getting to
life soon (sorry, quite busy, and I've got just a very little code done,
but will try to have a first version before the end of the week)
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Input devices capplets

[Rodrigo Moya]

On Wed, 2007-10-31 at 16:27 -0400, Matthias Clasen wrote:
 On 10/31/07, Jürg Billeter [EMAIL PROTECTED] wrote:
  On Wed, 2007-10-31 at 18:59 +0100, Denis Washington wrote:
   I created two mockups for possible keyboard and mouse capplets in GNOME
   2.20. Their aim is to incorporate accessibility features in both; the
   existing keyboard a11y features into Keyboard and the already discussed
   Mousetweaks settings into Mouse. The mockups can be found here:
  
   Keyboard: http://ultimum-projekt.de/mockups/keyboard.html
   Mouse:http://ultimum-projekt.de/mockups/mouse.html
  
   What do you think?
 
  Shouldn't we also incorporate the Keyboard Shortcuts capplet into the
  Keyboard capplet at the same time? Otherwise good work, as far as I can
  tell from a quick look.
 
  I don't think there was sufficient agreement that shortcuts have much
 if anything to do with the other keyboard settings.

right, and it would make the keyboard capplet too crowded. Since there
is the mousetweaks discussion going on, what about having shortcuts and
mousetweaks into an 'input devices actions' (find a better name)
capplet?
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Input devices capplets

[Rodrigo Moya]

On Wed, 2007-10-31 at 18:59 +0100, Denis Washington wrote:
 Hi,
 
 I created two mockups for possible keyboard and mouse capplets in GNOME
 2.20. Their aim is to incorporate accessibility features in both; the
 existing keyboard a11y features into Keyboard and the already discussed
 Mousetweaks settings into Mouse. The mockups can be found here:
 
 Keyboard: http://ultimum-projekt.de/mockups/keyboard.html
 Mouse:http://ultimum-projekt.de/mockups/mouse.html
 
 What do you think?
 
I think they look good, given we can't really merge them on a single
capplet. The keyboard capplet has many tabs, but this is much better
than having separate a11y capplets, so, unless something better is
proposed, you've got my vote :)
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Mousetweaks usability discussion

[Rodrigo Moya]

On Tue, 2007-10-30 at 19:20 +0100, Vincent Untz wrote:
 Le samedi 13 octobre 2007, à 14:25 +0200, Francesco Fumanti a écrit :
  Hello,
 
  During the accessibility summit last weekend, an new accessibility 
  application called Mousetweaks was presented:
  http://mail.gnome.org/archives/gnome-accessibility-devel/2007-October/msg00022.html
 
  In order to make it more gnome conform, its user interface will probably 
  have to be reviewed. I prepared a wiki page for that purpose which should 
  provide most relevant informations:
  http://live.gnome.org/mousetweaks/usability
 
 I don't know if control center people are aware of this effort, so I'm
 cc'ing them: all this has some impact on the current capplets.
 
we are discussing about an 'input devices' capplet, so not sure how this
fits in. Maybe we should look at how mousetweaks could be integrated
into this new capplet, although it would add lots of settings just for
the mouse.

Any other comments?
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: linuxMint's gnome-menu

[Rodrigo Moya]

On Wed, 2007-10-10 at 12:43 -0500, Benjamin Gramlich wrote:
  Do you mean the one pictured 
  http://linuxmint.com/pictures/screenshots/celena/mintmenu.png?
 
 Yeah, that's the one. Sorry I wasn't more clear and didn't attach a link
 to a picture. It's not a drop-in replacement for the current gnome-menu,
 but it has some excellent features:
 
 1) The search field
 2) You can mouse over Submenus to pull up the menuItems
 3) It's pretty
 4) The favourites menu
 
 It's written in python right now, and it's a little unresponsive at
 times when other programs are running.
 
 Also, since the gnome control center seems to be aiming to incorporate
 all the Preferences and Administration capplets, we could eventually
 remove these Submenus from the gnome-menu and have just the control
 center available. In any event, if the gnome-menu does undergo a
 redesign, it'd probably best to implement it first as an option between
 the classic menu and the new menu.
 
you are describing gnome-main-menu, which is already in GNOME's SVN and
whose code (part of) is already being used in the control-center. And it
does everything you listed here.

If we are going to use something like this, let's use what we already
have available
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: Pulseaudio

[Rodrigo Moya]

On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote:
 Hi,
 
 I'm new to this list, so sorry if I ask something already discussed.
 
 It has been a while since esound has received some attention - releases
 are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
 is the stronger candidate between alternatives, and that it allows for
 quite a lot of nifty things.
 
 I'm running pulseaudio since four or five months now on two of my
 desktop systems, both x86 and PPC, and I must say that I'm really
 satisfied by it. 
 It's quite stable and has very few compelling bugs for the normal user
 (e.g. when using it as an esound replacement on a machine with more than
 a logged in user it doesn't share the esd socket, or similar).
 
 It also seems to be actively developed, and is shipped by default with
 Fedora 8.
 
 Can it be eligible for inclusion in GNOME 2.22?
 
it looks pretty neat from what was shown at the Boston summit, so yes,
I'd vote for its inclusion, although some more integration work needs to
be done, but I think it's perfectly doable for 2.22.
-- 
Rodrigo Moya [EMAIL PROTECTED]

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

Re: GNOME Panel++

[Rodrigo Moya]

On Mon, 2007-09-24 at 16:41 -0500, Benjamin Gramlich wrote:
 Gimmie is very interesting and user friendly. I've always felt that the
 Gnome panel has been a little bare. SLED was a step in the right
 direction, but it seems that very few people have been willing to use
 it. (Actually, isn't Novell the only merchant to use SLED?)

yes, mainly because SLED is SuSE Linux Enterprise Desktop, the name of
the desktop distro sold by Novell :-) I guess what you mean is the
gnome-main-menu applet, right?

 I think that the gnome-panel could benefit very much from a redesign
 that would blend the OSX dock concept with its current UI. Maybe
 blending some of gimmie's great ideas with some of SLED's improvements.
 Gimmie would need to be implemented in C, though, wouldn't it?
 
unless there are very big performance issues, which I doubt, I see no
reason to rewrite a working software that already uses a free software
platform.
-- 
Rodrigo Moya [EMAIL PROTECTED]

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