Re: GNOME Goal: XDG config folder implementation
Luca Ferretti wrote: http://live.gnome.org/GnomeGoals/XDGConfigFolders [1] The migration from 2.x to 3.x is a good time to perform this, isn't it? :) [1] note: by now it's only a proposal Indeed this should be targeted for 3.x. Have a nice day :) - Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal: XDG config folder implementation
2010/6/6 Sven Pfaller : > Luca Ferretti wrote: >> >> http://live.gnome.org/GnomeGoals/XDGConfigFolders [1] >> >> The migration from 2.x to 3.x is a good time to perform this, isn't >> it? :) >> >> [1] note: by now it's only a proposal > > Indeed this should be targeted for 3.x. We have some nice examples to migrate configuration files to XDG config directory [1] and to put configuration data in XDG_CONFIG_DIRS [2] (Check the GnomeGoal page) So, +1 from me. Note that the application is a target for this goal if: - the application stores file in an hidden folder others than the XDG ones - OR if removing the .cache or the .config folders induces data loss for the user - OR removing the .config folder doesn't get the application in its default configuration See the GnomeGoal for more info. [1] http://git.gnome.org/browse/empathy/commit/?id=6fa59ef0e20828af6404821b198468ae3a9ef158 [2] http://git.gnome.org/browse/empathy/commit/?id=e1fa17399fc137a508f195aa6976b5f32189de96 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings schema paths: time to do some cleaning?
On Thu, Jun 3, 2010 at 12:56 PM, Milan Bouchet-Valat wrote: > Hi! > > I was wondering what kind of schema paths should adopt during the > migration to GSettings. Old GConf paths feel really lame, since we > basically put everything into /apps, with a few general settings going > to /desktop. Only /system really makes sense. This reminds people of the > horrid Windows Registry's HKEY_CLASSES_ROOT and friends! ;-) > > If we want to choose a better way of organizing schemas, the time is > now. What about going with something similar to D-Bus, > with /org/gnome/my-app? This feels pretty natural, and settings would be > sorted much more logically. For most simple schemas, name and path would > be equivalent (i.e. org.gnome.my-app), which makes sense. System-wide > settings could go into /system. Or do we want two top-level > directories, /user and /system? > > The migration docs don't say a word about this, and Ryan told me he > hasn't planned anything for that. So let's discuss this before it's too > late! Good point. So, here is my take on it: /system in gconf doesn't make much sense to me - there is nothing system-wide about the settings that I store there in my users gconf db. The split between /apps and /desktop in gconf was meaningful initially, but the meaning has been eroded over time. Originally, /apps/foo would take app-specific settings of app foo, and things below /desktop would be settings that are used by most things in the desktop (e.g. /desktop/gnome/interface/...) I think it would make sense to keep the app-specific vs desktop-wide split. Not sure if we need to change the paths from /apps/foo to /org/gnome/foo and from /desktop/gnome/xyz to /org/gnome/desktop/xyz. Wrt. to system-wide settings, I think we will to address this in the docs once the polkit support in gsettings/dconf settles (should be done by next week, I think). Matthias > Cheers > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 01:37, Lucas Rocha wrote: > Hi all, > > The release team would like to propose some important changes in the way we > organize our modulesets. GNOME releases are currently organized into the > following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev > Tools. This model has served us well and has actually evolved through time - > we > didn't have the Admin and Dev Tools modulesets initially. However, we feel > that > this organization is reaching its limits, and we have explored several > potential changes. > > Current issues > -- > > A set of issues makes it clear the need for an evolution here: > > 1. The arbitrary separation between Platform and Bindings can lead people to > think that the bindings are second-class citizens while this is certainly not > the case. Moving bindings modules to the Desktop moduleset won't make them less second-class citizens as long as API that is not bindable without resorting to language-specific glue code keeps being added to Platform. Examples of this are GVariant (which affects GSettings) and GDBus, in the latter this question was raised on gtk-devel but nobody showed interest in how to make the new functionality available to bindings: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html I don't think the authors of those APIs are to blame for this, because they asked for feedback before merging and nobody who cared about non-C languages replied. It's nice that the release team worries about bindings because lots of software is written for GNOME in languages other than C. But today we are seeing a disproportion between the people who use bindings and those that build them and it worries me a lot. What will happen to those applications when old APIs such as GConf are not available any more and GSettings is not available to their language? An action more in accordance with the intention of making bindings a first class citizen would be to require new API (with exceptions for low level glib stuff) to be bindable by the introspecting bindings, and also maybe some thinking into why the bindings landscape is in such a mess right now. Could be something like this be added to the criteria for platform libraries? Presently, we have this stub for what is considered as "bindable": http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! OK, as the discussion calmed down a bit I wanted to make some more constructive comment to the new module organization. I feel that there are a couple of (utility) applications that should be part of GNOME (e.g. the Desktop module set). This is a subset of the current application in the Desktop module even if they are not necessary for getting the session up. I left out the things that are necessary to start the session and I also left out accessibility but simply because I have nearly no idea about those modules. Someone should add those please. * bug-buddy (the point is that most distros don't use it so maybe we should remove it) * evince * eog * file-roller * gcalctool * gedit * gnome-terminal * nautilus * seahorse * totem * yelp These are the minimal requirements I see for a desktop computer to have, whatever the purpose of this computer is. These should probably also integrated tightly into the desktop so that the user doesn't even see them as real applications. In addition I would propose to have an "Applications" module where modules are included that are * Hosted on gnome.org (git, translations, etc.) * Follow the rules here http://live.gnome.org/ReleasePlanning/ModuleProposing * Have an UI, documentation and accessibility review if possible It might be a good idea to create some subcategories here like Online (evo, empathy, epiphany), Multimedia (rhythmbox, etc.), DevTools, Photos, Utilities (hamster, etc.). This list should be reviewed before every release and old and unmaintained stuff should drop out while new stuff can go it. It would be OK to have more than one application for the same purpose. The "Applications" set should be rather strict in the requirements. Better keep it small and good, but it would be a great place to promote high-quality applications and not as abstract as "some promotion on the web site". Just my 2 cents, Johannes P.S: Background of my proposal for specific things that may look strage at first sight (some examples): * evolution: Many people just use webmail * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly a requirement so. * sound-juicer/brasero: I had them on the list and realized then that there are many devices without an optical drive. 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: Modulesets Reorganization
Hi all! Other GNOME translators have already commented on this proposal, but I thought I'd share some of my views from the i18n/l10n point of view anyway. Michael Terry , Wed, 2 Jun 2010 08:54:49 -0400: > On 1 June 2010 19:37, Lucas Rocha wrote: > > 3. We strongly believe that we should encourage a strong ecosystem of > > apps around GNOME, and integrating all applications in the GNOME > > Desktop moduleset is not the best way to achieve this. > > As the maintainer of Déjà Dup, I approve of this move. I feel Déjà > Dup is a bit of a poster child for this change. Please note that the said proposal would very likely affect the l10n processes for many modules in a rather negative way. In particular, not providing (or not being required to do so) the translators a possibility for a sufficiently long string freeze period means that they aren't able and motivated to work on completing the l10n task before the module release. So I think, since i18n and l10n have long been core values for the GNOME Project, that having a clear release schedule and string freeze period shouldn't be just appreciated & encouraged from GNOME module maintainers, but simply required in order to ensure that GNOME l10n in a variety of languages is complete, consistent, and of reasonable quality. Furthermore, GNOME maintainers should always enable translators from the GNOME Translation Project (only) to work on module l10n using GTP in-house infrastructure. Adhering to other l10n projects or infrastructures goes against the fact that not other l10n project, but the GTP is and has been responsible for how the GNOME software is localized. The way how code development works is often confused with how l10n works, but these processes are different. For a working l10n effort, it's often quite more important to make use of centralized, normative infrastructure for a set of software projects that are to be localized with standardized team work flow, task planning, providing and sharing best practices, incl. sufficient consistency in translation terminology, style, etc. This all can be hardly accomplished when you have to deal with zillions of different l10n platforms, teams, release schedules and so on. In other words, working on GNOME translations should mean working within one translation project, with one language team, on one platform. So as I'm quite concerned over the future of the GNOME l10n efforts, it's my hope that the reorganization proposal won't be approved in its current form. Thanks, Petr Kovar ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
2010/6/6 Tomeu Vizoso : > On Wed, Jun 2, 2010 at 01:37, Lucas Rocha wrote: > > Presently, we have this stub for what is considered as "bindable": > > http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs Thanks a lot for that info. Just added a note about that in http://live.gnome.org/GTK+/BestPractices Regards, -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le dimanche 06 juin 2010 à 19:53 +0200, Tomeu Vizoso a écrit : > > Moving bindings modules to the Desktop moduleset won't make them less > second-class citizens as long as API that is not bindable without > resorting to language-specific glue code keeps being added to > Platform. > > Examples of this are GVariant (which affects GSettings) and GDBus, in > the latter this question was raised on gtk-devel but nobody showed > interest in how to make the new functionality available to bindings: > > http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html > > I don't think the authors of those APIs are to blame for this, because > they asked for feedback before merging and nobody who cared about > non-C languages replied. > > It's nice that the release team worries about bindings because lots of > software is written for GNOME in languages other than C. But today we > are seeing a disproportion between the people who use bindings and > those that build them and it worries me a lot. What will happen to > those applications when old APIs such as GConf are not available any > more and GSettings is not available to their language? > > An action more in accordance with the intention of making bindings a > first class citizen would be to require new API (with exceptions for > low level glib stuff) to be bindable by the introspecting bindings, > and also maybe some thinking into why the bindings landscape is in > such a mess right now. While I agree with you case about the importance of bindings, I don't see why GSettings shouldn't work with bindings. For GNOME Shell, we had a few issues with g_settings_get_strv() and g_settings_set_strv(), but the API was quickly improved, and now GObject introspection allows us to use GSettings from JavaScript via GJS without any flaw. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Sun, Jun 6, 2010 at 21:57, Milan Bouchet-Valat wrote: > Le dimanche 06 juin 2010 à 19:53 +0200, Tomeu Vizoso a écrit : >> >> Moving bindings modules to the Desktop moduleset won't make them less >> second-class citizens as long as API that is not bindable without >> resorting to language-specific glue code keeps being added to >> Platform. >> >> Examples of this are GVariant (which affects GSettings) and GDBus, in >> the latter this question was raised on gtk-devel but nobody showed >> interest in how to make the new functionality available to bindings: >> >> http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html >> >> I don't think the authors of those APIs are to blame for this, because >> they asked for feedback before merging and nobody who cared about >> non-C languages replied. >> >> It's nice that the release team worries about bindings because lots of >> software is written for GNOME in languages other than C. But today we >> are seeing a disproportion between the people who use bindings and >> those that build them and it worries me a lot. What will happen to >> those applications when old APIs such as GConf are not available any >> more and GSettings is not available to their language? >> >> An action more in accordance with the intention of making bindings a >> first class citizen would be to require new API (with exceptions for >> low level glib stuff) to be bindable by the introspecting bindings, >> and also maybe some thinking into why the bindings landscape is in >> such a mess right now. > While I agree with you case about the importance of bindings, I don't > see why GSettings shouldn't work with bindings. Yes, I was referring to g_settings_get_value/g_settings_set_value which is the most general API. So while part of the functionality is available to bindings there's some that isn't. Which wouldn't be so bad if at least there was an alternative API for bindings that providing the missing functionality. Similarly, I'm sure part of the GDBus API is callable via introspection, but some isn't. > For GNOME Shell, we had > a few issues with g_settings_get_strv() and g_settings_set_strv(), > but the API was quickly improved, and now GObject introspection allows > us to use GSettings from JavaScript via GJS without any flaw. If GJS is able to call those methods right now, you may need to remove some workaround there when this patch lands: https://bugzilla.gnome.org/show_bug.cgi?id=620170 (Testing, comments and review welcome, btw) Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Sun, Jun 6, 2010 at 8:55 PM, Johannes Schmid wrote: > Hi! > (...) Hey, before addressing any specific point I just want to say that I pretty much agree with the spirit of the Release Team's proposal, if not with all its details, and that I'd rather see us engage in a bit of too much destructive force on our desktop in order to sharpen our vision than die of the infamous one thousand cuts of a directionless moduleset that has, probably, grown a bit more than it should have. With that being said... > > P.S: Background of my proposal for specific things that may look strage > at first sight (some examples): > * evolution: Many people just use webmail > * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly > a requirement so. It's very much true that for a long time pretty much every distribution has shipped browsers other than epiphany as default, even when they picked gnome as their default desktop environment. Historically firefox has been this browser, and seeing recent trends I wouldn't be surprised with chromium taking its place in the future. This has made epiphany the odd duck in the eyes of many, and given that, it's not surprising at all to see proposals like the one Johannes makes. I only want to answer with two ideas, one which should be obvious but perhaps isn't, and other than hopefully looks towards a different future for epiphany. The obvious idea is that basing our decisions on what distributions do is absolutely the wrong way of doing things. There's many distributions around, and no matter what we do there will be always some that will ignore decisions that the upstream community considers core foundations of the software we work on. This is one of the bittersweet facets of free software, and there's not really a lot to be done about it. What we *can* do, though, is work as hard as we can in shaping a coherent idea that the combination of our modules form, and make it compelling enough that most people wouldn't dream of taking it apart to build something else because they would be giving their users an impoverished experience. I don't think we should be satisfied with anything less than that. The idea for the future is that we would like to change the vision people have of epiphany. Some time ago we decided to switch our engine and work on replacing gecko with a native port of webkit for our platform. Saying that this is hard work would be an understatement, but thanks to the work of many people and companies, including a tremendous effort by the one I work for, I think we are doing great progress in bringing this new crazy thing we call the web to our platform in a way that does not feel alien to it. The problem, of course, is that users don't use APIs directly, and we still have much to do in making things usable for them. If we all agree that the web is a vital part of any modern environment we must use the opportunity we have and blend epiphany with the shell and all the other parts of gnome in one indivisible unit. Let's integrate it deep into the core experience, going where no other browser can, or would dare to, go because no other browser can break the compromises needed to sort-of-work in every possible linux environment. I've always seen this as the role epiphany should play, and at least for myself I'm more than willing to go there as long as we can figure out something that we feel makes sense for us now and in the future. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Johannes, I really like your ideas: On Sun, 2010-06-06 at 20:55 +0200, Johannes Schmid wrote: > Hi! > > OK, as the discussion calmed down a bit I wanted to make some more > constructive comment to the new module organization. I feel that there > are a couple of (utility) applications that should be part of GNOME > (e.g. the Desktop module set). This is a subset of the current > application in the Desktop module even if they are not necessary for > getting the session up. I left out the things that are necessary to > start the session and I also left out accessibility but simply because I > have nearly no idea about those modules. Someone should add those > please. > > * bug-buddy (the point is that most distros don't use it so maybe we > should remove it) > * evince > * eog > * file-roller > * gcalctool > * gedit > * gnome-terminal > * nautilus > * seahorse > * totem > * yelp > > These are the minimal requirements I see for a desktop computer to have, > whatever the purpose of this computer is. These should probably also > integrated tightly into the desktop so that the user doesn't even see > them as real applications. > Agreed - I think this is a really good list. > In addition I would propose to have an "Applications" module where > modules are included that are > * Hosted on gnome.org (git, translations, etc.) > * Follow the rules here > http://live.gnome.org/ReleasePlanning/ModuleProposing > * Have an UI, documentation and accessibility review if possible > I also agree - I think being hosted on GNOME infrastructure is a key requirement (and I'm confused whether this is a requirement in the new module proposal from the release team). I think being hosted on GNOME infrastructure will help with documentation, translations and accessibility. > It might be a good idea to create some subcategories here like Online > (evo, empathy, epiphany), Multimedia (rhythmbox, etc.), DevTools, > Photos, Utilities (hamster, etc.). This list should be reviewed before > every release and old and unmaintained stuff should drop out while new > stuff can go it. It would be OK to have more than one application for > the same purpose. > I really like this idea. I think it addresses some of the other concerns that have been brought up. > The "Applications" set should be rather strict in the requirements. > Better keep it small and good, but it would be a great place to promote > high-quality applications and not as abstract as "some promotion on the > web site". > > Just my 2 cents, > > Johannes > > P.S: Background of my proposal for specific things that may look strage > at first sight (some examples): > * evolution: Many people just use webmail > * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly > a requirement so. > * sound-juicer/brasero: I had them on the list and realized then that > there are many devices without an optical drive. --Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! > The idea for the future is that we would like to change the vision > people have of epiphany. Some time ago we decided to switch our engine > and work on replacing gecko with a native port of webkit for our > platform. Saying that this is hard work would be an understatement, > but thanks to the work of many people and companies, including a > tremendous effort by the one I work for, I think we are doing great > progress in bringing this new crazy thing we call the web to our > platform in a way that does not feel alien to it. I see your point here and that was one of the reasons it put the "unsure" in front of the comment about epiphany. If we create a user-experience inside GNOME 3.0 with integrated web-browsing that rocks we very well should include it. Is there some kind of RoadMap for this or concrete plans? A quick look at the wiki didn't reveal anything. Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
