Re: Module Proposal: Zeitgeist
There is the further issue of translation. The Bulgarian team had prepared a translation to Zeitgeist available here: http://fsa-bg.org/project/gtp/browser/gnome/gnome3/zeitgeist.trunk.bg.po We could not import it to Launchpad because a team member there had locked the translation. (and we had another team member cooperating with us who could not help, it seems locking in Launchpad is really exclusive). I would really expect a module this central to GNOME to be administered using the usual GNOME infrastructure. Otherwise there is pressure put on long time GNOME contributors and our work is made more difficult. Kind regards: al_shopov ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Mikkel, On Thu 22 Apr 2010 21:40, Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com writes: Here's what we do. We set a series of milestones and target bugs and blueprints to these milestones. We also attach branches (not patches) to bugs and blueprints. When a linked branch is ready to merge into another branch (trunk or other) we add a merge request, which enables the review system. It's not as slick as launchpad, but have you tried bgo's splinter? One can push git branches to bugzilla, and review the patches on the web, with a quite acceptable interface. Just a data point :) We create sub teams and sub projects that all have different rights and responsibilities. So basically we use pretty much all aspects of a modern project hosting solution. Bugzilla is just a bug tracker. Obviously you have to do what's best for you, but I have found it best to rely on a more flat technical rights division -- for example, either you're in the project or you're out, and most people that want to should be in. Rights and responsibilities can in many cases be managed better on the social level, with trust. This also allows people to migrate to different areas of resposibility over time. YMMV, of course. Happy hacking, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2010/4/23 Александър Шопов li...@kambanaria.org: There is the further issue of translation. We already agreed that translations can be moved to GNOME infrastructure. I've just committed the translation, btw. Thanks! -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings and you, II
I have just released GLib 2.25.2 and GConf 2.31.2. These release contain the accumulated bug-fixes that came out of the early adoption after my .1 releases earlier this week. Overall, things should be pretty solid now, so if you hesitated to jump last time, now is an even better time. Some noteworthy changes: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 - The .pc variables for schema compilation have changed (but you should really use the AM_GSETTINGS macro anyay) - We install a 'gsettings' utility that gives you commandline access to your settings, similar to gconftool-2 - Robustness and correctness fixes in gsettings-schema-convert and gschema-compile - gsettings-data-convert expects its keyfiles in /usr/share/GConf/gsettings now Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
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, II
В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On Fri, 2010-04-23 at 11:54 +, Yavor Doganov wrote: В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. What do you recommend replacing it with? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
В Fri, 23 Apr 2010 13:23:56 +0100, Bastien Nocera написа: This is a good opportunity to stop abusing Automake's macro namespace, What do you recommend replacing it with? GLIB_GSETTINGS seems natural, as the glib package is the owner of the macro. (You can use AU_DEFUN to facilitate upgrades for the few packages that already use AM_GSETTINGS). Likewise, GTK_ is a good prefix for GTK+ macros, and GNOME_ is a good prefix for generic GNOME macros (that are currently in gnome-common and/or provided by libraries in the desktop suite). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On Fri, 2010-04-23 at 06:52 -0400, Matthias Clasen wrote: I have just released GLib 2.25.2 and GConf 2.31.2. These release contain the accumulated bug-fixes that came out of the early adoption after my .1 releases earlier this week. Overall, things should be pretty solid now, so if you hesitated to jump last time, now is an even better time. Some noteworthy changes: snip - gsettings-data-convert expects its keyfiles in /usr/share/GConf/gsettings now I still have a major problem with the backend selection in GSettings. If we were to run gsettings-data-convert on start-up, it would migrate from GConf to GSettings' keyfile backend. I would actually want GConf to GConf migration in this case, because I renamed the key. The backend selection is also completely broken if one were to use plugins from different applications. For example, gnome-bluetooth's wizard has plugins for application integration. Amongst those are a NetworkManager plugin, and a geoclue one. If one of those used GSettings with the gconf backend and the other GSettings with another backend, we'd have a real problem. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On 04/23/2010 07:54 AM, Yavor Doganov wrote: В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. Was just going to point this out. GLIB_GSETTINGS sounds right. Or maybe we should just have a GLIB_INIT([settings introspection ...]) kind of macro? Or, humm, what is the macro supposed to do again? behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
2010/4/23 Yavor Doganov ya...@gnu.org: В Fri, 23 Apr 2010 13:23:56 +0100, Bastien Nocera написа: This is a good opportunity to stop abusing Automake's macro namespace, What do you recommend replacing it with? GLIB_GSETTINGS seems natural, as the glib package is the owner of the macro. (You can use AU_DEFUN to facilitate upgrades for the few packages that already use AM_GSETTINGS). Bug and patch submitted here: [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=616648 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed magnifier DBus names
Anyone, A group of us have been discussing names for a DBus magnifier service. We have come to a consensus. Service names: org.gnome.magnifier org.gnome.magnifier.zoomregion Object names: /org/gnome/Magnifier /org/gnome/Magnifier/ZoomRegion Do you see any problems with these names? -- joseph 'Clown control to Mao Tse Tung.' - D. Bowie (misheard lyric) - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
I think it would be worth fleshing out some existing parts of the design, like the application menu and launchers, before delving in to gizmos as a separate component. In the end, if the rest is done to cover the appropriate jobs, they may not be necessary. One really dumb thing with gnome-panel applets today is that, in a lot of ways, we're arbitrarily categorizing these applications differently (because they're small) and putting them in a horrible menu that can't be accessed through primary interactions. Instead of being in, say, Applications›Finances, to get a cute stock ticker that's always available you need to right click the panel, choose Add to Panel… and search, and then position the applet somewhere. It's really totally arbitrary! Lots of smartphone OSs solve this with things like badges attached to application launchers. That approach alone seems to work very well. Gnome-shell, meanwhile, has a lot of pixels to play with ;) Thanks, Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed magnifier DBus names
On Tue, Apr 20, 2010 at 2:30 PM, Joseph Scheuhammer cl...@utoronto.ca wrote: Anyone, A group of us have been discussing names for a DBus magnifier service. We have come to a consensus. Service names: org.gnome.magnifier Should be org.gnome.Magnifier org.gnome.magnifier.zoomregion org.gnome.Magnifier.ZoomRegion Object names: /org/gnome/Magnifier /org/gnome/Magnifier/ZoomRegion Looks good! I think http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions leaves some room for interpretation, but my advice complies with the spec and with most GNOME d-bus names that I see. Sandy Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
new module proposal: gobject-introspection
GObject Introspection in the bindings set --- I'd like to propose GObject Introspection as part of the bindings release set. Introspection is an infrastructure tool for both applications and language bindings. For more background, there's a longer description of what introspection does here: http://live.gnome.org/GObjectIntrospection External Dependencies: Introspection currently depends on Python 2.5 or later for the developer tools *only*. Adoption: We have several binding consumers of introspection (seed/gjs, pygi, sbank, jgir) in various stages. We've made a good amount of progress in allowing Vala to be rebased on introspection as well (though there is one major blocker still left for that). Gnome-shell currently depends on introspection as a way to bind mutter core. GNOME-ness: We feel we're fairly thoroughly GNOMEy =) 3.0 readiness: Relevant in the sense that introspection is a dependency of gnome-shell which we would like to brand as GNOME 3. We don't link to any GTK+ so there's no GSEAL etc. to worry about. License: LGPL 2.1+, a bit of BSD code here and there Now, on to concerns/issues. 1) gir-repository should be dead - people please stop depending on it. It's pretty high priority for me to get gnome-shell switched over to the GTK+ introspection built stack. 2) API/ABI stability. I'm going to try really hard on this. If we end up doing nested namespaces for Vala some things will get harder, but we'll see. 3) Will this conflict with the eventual goal of getting introspection into GLib? My feeling here is that we can preserve typelib compatibility, potentially only the libgirepository API would change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. I think Launchpad + BZR and GNOME + git can interoperate fine. 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 * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. You can request a rescan of GNOME git (takes about 5 minutes) to get the changes back to Launchpad. If you need assistance, I can help. If I cannot help, I am sure someone from the launchpad-code team can explain the workflow. -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. I think Launchpad + BZR and GNOME + git can interoperate fine. 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 * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. You can request a rescan of GNOME git (takes about 5 minutes) to get the changes back to Launchpad. If you need assistance, I can help. If I cannot help, I am sure someone from the launchpad-code team can explain the workflow. I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. If the Zeitgeist community is centered around Launchpad and bzr and wants changes submitted as launchpad branches, but it happens that you can check it out of GNOME git, that's not being part of the GNOME community. (A secondary point is definitely being part of our translation infrastructure so that the translators can make sure that GNOME is properly translated into their languages without having to join and participate in some different translation community.) As for the external dependency question - certainly there are other components like GStreamer and Clutter that are external dependencies despite being closely tied in with the GNOME platform. However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: gobject-introspection
Hi, On Sat, Apr 24, 2010 at 12:05 AM, Colin Walters walt...@verbum.org wrote: We've made a good amount of progress in allowing Vala to be rebased on introspection as well (though there is one major blocker still left for that). The nested namespace issue you mentioned below? 1) gir-repository should be dead - people please stop depending on it. It's pretty high priority for me to get gnome-shell switched over to the GTK+ introspection built stack. Isn't death of gir-repository awaiting for moving all gir/typelib to respective libraries rather than for applications to stop depending on gir-repository? 2) API/ABI stability. I'm going to try really hard on this. If we end up doing nested namespaces for Vala some things will get harder, but we'll see. Talking of namespaces, is it correct that gir does not allow multiple libs to share a namespace? If so, that could be bigger issue than not supporting nested namespaces AFAICT. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 24, 2010 at 4:29 AM, Owen Taylor otay...@redhat.com wrote: On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: I think Launchpad + BZR and GNOME + git can interoperate fine. [snip] I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. [snip excellent points] However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. I was ambivalent to this discussion, but Owen has swayed me and I completely agree with him now. I think this discussion has been trying to follow the letter of the rules, but the intent has been forgotten. One of the intents of the rules is to prevent fragmentation of development, the codebase, and the community. Another is to allow people (and distributors) to only need to follow one source of information (the GNOME infrastructure) to work with upstream. This is how GNOME's workflow is organised. If Zeitgeist goes outside this; then it disrupts everyone's workflow whenever they need to interact with Zeitgeist. The external deps rule was added out of necessity; some projects are more than just GNOME-centric; and belong on freedesktop, or a completely/mostly DE/OS-agnostic infrastructure such as sourceforge, github, code.google.com, launchpad, etc. We cannot say Python must use GNOME infrastructure before python apps are allowed in the GNOME stack; but we *can* say that for Vala because it was developed specifically for use with the Glib/GNOME stack. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
