Re: Status and future of pessulus in GNOME3?
Hi Manish, Le vendredi 01 mars 2013, à 02:00 -0700, Manish Sinha a écrit : I just wanted to know if pessulus has any future roadmap? With GNOME3 having changed the lockdown method, is there any plans of implementing a GUI for lockdown? I wanted to take this up as a GSoC project if it is still in any kind of roadmap - official or non-official. Ah, I might not have been explicit enough in our private discussion, but it might be worth focusing on the lockdown story in our platform first. And I think this is where people on ddl can help you plan for a GSoC project. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-Session
Le dimanche 27 janvier 2013, à 00:30 +0100, Lanoxx a écrit : Hi, in the man page of gnome-session I cannot find any explanation or reference about the following fields in a .session file: I guess it's best to look at /usr/share/gnome-session/sessions/gnome.session as an example if the man page doesn't cover this. IsRunnableHelper and This is the path to a binary that is executed by gnome-session to know if the evaluated session can run or not. The exit value of the process is used for that. For instance, right now, we use @LIBEXECDIR@/gnome-session-check-accelerated that checks if hardware acceleration is available to determine if gnome-shell can run or not. (I guess this will change to allow llvmpipe in 3.8) FallbackSession This is the name of the other session that will be used if the IsRunnableHelper test failed. For instance, in 3.6 and earlier, it was gnome-fallback as the fallback mode was used when hardware acceleration wasn't available. DesktopName This is not used, not sure where you saw that. Additionally the man page mentions TASK in the context of required and default providers, but does not explain that in more detail. Where do get more information about what these tasks and providers are and what they reference? For example in one of my session files I find these lines: RequiredProviders=windowmanager; DefaultProvider-windowmanager=gnome-wm DefaultProvider-notifications=notify-osd Who do I know what the TASKs windowmanager and notification are? Under which circumstances could I add another line with some other TASK and why would I want to do that? You can define anything as a task. The providers for a task are found in the .desktop files, thanks to the X-GNOME-Provides key. These .desktop files must either be in the autostart paths, or explicitly mentioned in DefaultProvider-TASK. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-Session
Le dimanche 27 janvier 2013, à 14:10 +0100, Lanoxx a écrit : On 27/01/13 09:02, Vincent Untz wrote: Le dimanche 27 janvier 2013, à 00:30 +0100, Lanoxx a écrit : DesktopName This is not used, not sure where you saw that. On Ubuntu all the session files have such a line. Then it's an Ubuntu-specific thing. Additionally the man page mentions TASK in the context of required and default providers, but does not explain that in more detail. Where do get more information about what these tasks and providers are and what they reference? For example in one of my session files I find these lines: RequiredProviders=windowmanager; DefaultProvider-windowmanager=gnome-wm DefaultProvider-notifications=notify-osd Who do I know what the TASKs windowmanager and notification are? Under which circumstances could I add another line with some other TASK and why would I want to do that? You can define anything as a task. So what is a task used for and why whom? Does gnome-session just simply run any of the specified TASKs? The idea behind this is to allow alternative software to be used instead of some default part of GNOME. To be honest, it doesn't make much sense in GNOME 3 anymore, and it's more of a GNOME 2 thing. For instance, you could replace notification-daemon with notify-osd this way. Or metacity with compiz. The example you gave with anjuta doesn't make much sense, though, as it's more about some parts needed for the desktop shell, not about applications. And the only use of this is the RequiredProviders line of the .session files. gnome-session will start the components providing those providers. The providers for a task are found in the .desktop files, thanks to the X-GNOME-Provides key. These .desktop files must either be in the autostart paths, or explicitly mentioned in DefaultProvider-TASK. So there should exist a gnome-wm.desktop and notify-osd.desktop file somewhere, yes? Could you give me the exact path where I can find it? Most likely /usr/share/applications/. Could I put a new line there and point it to any application's desktop file and it would get started, say for example anjuta? Yes, but as I said, it doesn't make much sense because this is not a part of the shell, but an app that you want to automatically start. It makes more sense to use the autostart spec for this: http://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html (ie: simply drop a .desktop file in /etc/xdg/autostart/) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-Session
Le dimanche 27 janvier 2013, à 15:32 +0100, Lanoxx a écrit : On 27/01/13 14:38, Vincent Untz wrote: Le dimanche 27 janvier 2013, à 14:10 +0100, Lanoxx a écrit : On 27/01/13 09:02, Vincent Untz wrote: Le dimanche 27 janvier 2013, à 00:30 +0100, Lanoxx a écrit : Where do get more information about what these tasks and providers are and what they reference? For example in one of my session files I find these lines: RequiredProviders=windowmanager; DefaultProvider-windowmanager=gnome-wm DefaultProvider-notifications=notify-osd [...] So I understand that the first two lines are related to each other. First its defined that there should be a required provider TASK named 'windowmanager' and then we specify that the default provider for this task is gnome-wm. I also found the .desktop file in /usr/share/applications. So far so good. RequiredProviders=windowmanager; DefaultProvider-windowmanager=gnome-wm But this line here is where I get confused: DefaultProvider-notifications=notify-osd There seems to be no other line that references a TASK named notifications and there is also no corresponding .desktop file in /usr/share/applications. What I do not understand is, how do I know what is a valid provider? It's probably worth checking in the code, but I think that it marks notify-osd as autostart, and give it a higher priority than other notifications providers (like notification-daemon). The fact that it's not in RequiredProviders simply makes the session not fail if notify-osd cannot be started. So it's not required, just recommended. Does gnome-session hard code the valid provider names somewhere in its soure, or is this some kind of interface that is known by the TASKS? No, anything can be used. What would happen if I just remove that line, would the notification system stop working? Yes, assuming there's notify-osd or notification-daemon defined in the autostart path. Now, it's worth mentioning that all this is gone in 3.8, see http://git.gnome.org/browse/gnome-session/commit/?id=098fad4ea1be6953f66fc457df1943a31247611a Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.8 feature: Drop or Fix Fallback Mode
Hi Brian, Le lundi 22 octobre 2012, à 14:08 -0500, Brian Cameron a écrit : I would say that it is very probable that people at Oracle could be found to help with maintainership duties for particular GNOME Fallback modules if help like this is needed. I think it's clear that help like this is needed if we want to keep the fallback mode alive. Do you think it's possible to see some Oracle people step up in the next few weeks? Or, perhaps it would be useful to setup a forum where people interested in GNOME Fallback can focus discussion on how to fix high priority bugs. I think there are people at Oracle who would like to participate in more discussion about GNOME portability and fallback mode if it were more clear where discussion was being held. Is there any reason desktop-devel-list wouldn't work for this? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le vendredi 19 octobre 2012, à 12:07 -0400, Colin Walters a écrit : On Fri, 2012-10-19 at 15:48 +0200, Bastien Nocera wrote: I would recommend that gnome-shell uses systemd to suspend, and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. But in reality, the set of git repositories forms a whole. And if gnome-settings-daemon doesn't support !systemd, then the whole doesn't either. So if you decide to delete this code from g-s-d, it makes the work of anyone else completely pointless. Broadly speaking, I don't think it makes sense for this to be up to individual module maintainers as they please, because the result is incoherent. +1. This is exactly the kind of stuff that, at least from my perspective, was raised during the AGM at GUADEC. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Recommended office suite?
Le lundi 03 septembre 2012, à 08:59 +0200, Frederic Peters a écrit : Mattias Eriksson wrote: I'm also under the impression that there are a lot of support for LibreOffice in the Gnome community, and I was told that Documents has a dependency on it (causing Documents not to be included in the Gnome Ubuntu flavor). I do not know of such a dependency. Documents uses unoconv to be able to show the quick preview of office documents (iirc). It's not a hard dependency, though. It will still work if unoconv is not installed. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings are not saved
Le lundi 27 août 2012, à 08:37 +0200, Lanoxx a écrit : On 27/08/12 07:37, Vincent Untz wrote: Le lundi 27 août 2012, à 01:37 +0200, Lanoxx a écrit : The reason was also that my schema did not have a path set. But for some reason panel_applet_settings_new() does not warn about this, when I switched to g_settings_new() i got a Gtk-Critical exception, thats when I noticed my schema needs a path. As I said, panel_applet_settings_new() is a wrapper around g_settings_new_with_path(). That's why you don't need a path in the schema -- the path is defined by gnome-panel for your applet. Vincent In that case, there is probably a bug in that function, see my following patch here, these few lines completely fixed it for me: And this change is fine. The settings won't be per-applet, though, but for all instances of this applet. Note that, afaik, g_settings_new_with_path() works fine. It's used in several applets. See for instance http://git.gnome.org/browse/gnome-panel/tree/applets/fish/fish.c#n1438 Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings are not saved / Gnome Panel Crash
Le lundi 27 août 2012, à 10:54 +0200, Lanoxx a écrit : On 27/08/12 10:41, Lanoxx wrote: On 27/08/12 08:56, Vincent Untz wrote: Note that, afaik, g_settings_new_with_path() works fine. It's used in several applets. See for instance http://git.gnome.org/browse/gnome-panel/tree/applets/fish/fish.c#n1438 Now you confused me. In this link there is no call to g_settings_new_with_path(). And also I can't find any schema definition for the key |FISH_SCHEMA.| Again, panel_applet_settings_new() is a wrapper around g_settings_new_with_path(). So that's FISH_SCHEMA is defined at: http://git.gnome.org/browse/gnome-panel/tree/applets/fish/fish.c#n52 Ok, now try this: Add wanda the fish to the gnome panel. Then right click - preferences - set frame rate to 0.2 (original 0.3). Close and remove wanda from the gnome panel. Now go to Add to panel click on wanda - add This crashes my whole gnome panel. Can you confirm this? Hrm, nope, it works here. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings are not saved
Le dimanche 26 août 2012, à 19:15 +0200, Lanoxx a écrit : Maybe panel_applet_settings_new should get the comment in the docs, that it does not retain the settings. Not sure what you mean -- the settings should definitely be saved. panel_applet_settings_new() is simply a wrapper around g_settings_new_with_path(), with a path provided by gnome-panel. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings are not saved
Le lundi 27 août 2012, à 01:37 +0200, Lanoxx a écrit : The reason was also that my schema did not have a path set. But for some reason panel_applet_settings_new() does not warn about this, when I switched to g_settings_new() i got a Gtk-Critical exception, thats when I noticed my schema needs a path. As I said, panel_applet_settings_new() is a wrapper around g_settings_new_with_path(). That's why you don't need a path in the schema -- the path is defined by gnome-panel for your applet. Vincent On 26/08/12 20:21, Vincent Untz wrote: Le dimanche 26 août 2012, à 19:15 +0200, Lanoxx a écrit : Maybe panel_applet_settings_new should get the comment in the docs, that it does not retain the settings. Not sure what you mean -- the settings should definitely be saved. panel_applet_settings_new() is simply a wrapper around g_settings_new_with_path(), with a path provided by gnome-panel. Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: symbolic icons and non-Gnome system trays
Le mercredi 11 juillet 2012, à 15:31 -0400, Dan Winship a écrit : On 06/24/2012 02:34 PM, Shawn J. Goff wrote: Is a system-tray implementation supposed to theme the symbolic icons itself? Yes. Um, it's supposed to be in the systray spec, but the online versions of fdo specs rarely ever get updated. It's actually not in the spec, iirc. See http://cgit.freedesktop.org/xdg/xdg-specs/tree/systemtray/systemtray-spec.xml We should update it. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
fallback mode vs llvmpipe rendering
Hi all, People are contacting me every now and then about gnome-panel. There are several people willing to work on it to improve it, but more with the goal of making a GNOME 2-like session than a fallback session. So far, I've been accepting all contributions, except the ones that make the panel go in another direction than the fallback session. But there's an interest for going in other directions, and I don't want to block those motivated people if we don't need gnome-panel anymore for our official GNOME releases, which means if we don't need the fallback mode anymore. And now that llvmpipe rendering has been available for a few months, I wonder if we still need (or want) to keep the fallback session. If we want to keep the fallback mode, then: - obviously, we need to maintain all of the fallback components (at least metacity and gnome-panel) - we need to keep making sure the fallback experience doesn't degrade too much because of changes in other modules If we feel llvmpipe is enough: - we don't need to maintain metacity and gnome-panel as part of the official GNOME stack, and they can start a new life - we can get rid of some compatibility code in various modules for the fallback session - we probably need to work on forcing the use of llvmpipe when we know hardware acceleration won't work (see https://bugzilla.gnome.org/show_bug.cgi?id=672943) and find how to deal with zaphod multi-screen setups Whatever we choose, this would at least clarify the current situation, where some people think llvmpipe is the new fallback, while others believe we still need to keep alive the fallback components. For the record, I've no strong opinion on this myself. I might lean towards going the llvmpipe way so that the people who want to hack freely on the fallback components may do so. Oh, and the first person that drives the thread in a oh, I hate gnome-shell beause of XYZ, GNOME 2 was so much better direction will suffer eternal shame! Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fallback mode vs llvmpipe rendering
Le lundi 25 juin 2012, à 12:56 +0200, Olav Vitters a écrit : On Mon, Jun 25, 2012 at 11:05:43AM +0200, Vincent Untz wrote: But there's an interest for going in other directions, and I don't want to block those motivated people if we don't need gnome-panel anymore for our official GNOME releases, which means if we don't need the fallback mode anymore. And now that llvmpipe rendering has been available for a few months, I wonder if we still need (or want) to keep the fallback session. What kind of other direction? It is fallback because you need it for some hardware. The other direction would be more like GNOME 2 :-) Right now, we make the fallback behave a bit like GNOME Shell (at least visually, and for various bits of the basic interaction), and there have been requests to not do that. If llvmpipe is good enough (it only works on Fedora atm AFAIK), then we don't need fallback mode anymore. FWIW, I'd like to have that llvmpipe working on Mageia. Hrm, I think it's working on more than Fedora. It should be working on openSUSE Factory, and iirc, I've read that it works on Ubuntu too. Some people use fallback mode because it can be made to look like GNOME 2. Why not, all the better to them. However, if all the compatibility stuff is removed, is having just gnome-panel + metacity realistic? It seems that more and more stuff moves into gnome-shell (authentication dialogs, etc). As soon as the maintenance of gnome-panel + metacity is transferred to an you're on git.gnome.org, can do releases, but not actively thought of by the rest.. then we might just be first inviting people to contribute, but from then onwards making their lives difficult. It makes sense that everyone drops support for fallback mode... and IIRC, such support is even in gnome-control-center. True. On the other hand, I wouldn't say the fallback experience is awesome today. I'm not sure we even properly test it nowadays. If we decide to go that way, people could at least focus on rebuilding a GNOME 2 experience with additional components if they want to do so. This would be outside of our official product, but they wouldn't need to rely on our fallback code paths that might not be that great for a real GNOME 2 experience... Wondering: Would you still maintain or look after metacity+gnome-panel if there is no fallback mode? I'm not looking after metacity :-) For gnome-panel, I guess it depends. If people want to step up and actively develop it, I'll make room for them. Otherwise, I guess I'll keep it in maintenance mode for some more time. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some points about IM integration
Marguerite, (First, no need to cc me, I'm obviously subscribed to desktop-devel-list :-)) Le mardi 15 mai 2012, à 16:40 +0800, Marguerite Su a écrit : On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote: In general, choice of input method framework is not a goal in itself. If we choose a single input method framework to integrate with GNOME - that doesn't make GNOME like proprietary software from Apple and Microsoft, because GNOME will still be 100% Free Software, and will still be developed in the open by the GNOME community. GNOME doesn't want to work well just for tweakers and enthusiasts - it's very important to the project that GNOME works well for all users without tweaking. We want to give the choice of using Free Software to everybody - this is a much more fundamental form of choice than giving a small group of users the ability to swap out a different input method framework underneath GNOME. no offense, but if Chinese or CJK Community is a small group(I think I've already be clear about what CJK users are doing today. they'are the nowadays tweakers you called. why? because you didn't ship what they want. you know, IM is the most famous workaround in i18n world), GNOME Asia can be shutdown. so is Chinese or CJK Community a small group or second class? say that in public in Hong Kong. I feel you misunderstood what Owen wrote. My understanding is that when Owen is talking about a small group here, it would only be a small group because our goal is to have GNOME work well by default for most people, including most users of the CJK community. If we manage to do that, then only a small number of people would need to do some changes (like using a different input method framework). Now, there's obviously the question of whether this goal is achievable: can we cover the needs of most users (including most users of the CJK community) with one input method framework? Some people in this thread seems to think it's possible, while others believe it's not. I can't answer this as I've no background on input methods in general. It would surely help to have some simple wiki page summarizing the current state of ibus and fctix, both as frameworks in general as well as for the availability and state of their plugins. People have been trying to tell the pros and cons of both in various mails, but I don't think anybody really managed to get a global view because of the number of mails. [...] GNOME isn't just a set of parts that a Linux distributor takes and uses to create a working system - we also take responsibility for creating a fully working system. This means deciding how GNOME interacts with system components like sound and networking and printing and when necessary enhancing those components to provide the right experience to the user. yes and no. your will is good and respectful. but have you ever discussed it with downstream distributions? I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will think on this. Hrm, I'm not sure what you expect me to say here :-) This is the way GNOME has been working for a while. For instance, this is why GNOME has tight integration with NetworkManager and PulseAudio. Of course, this raises challenges for integrators downstream (as well as for some advanced users) and I'm very well aware of this. But we feel (where we = GNOME) it helps us build a better user experience. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Hi, Le lundi 23 avril 2012, à 23:23 +0200, Rui Tiago Cação Matos a écrit : Hi, The GNOME desktop has, up until now, supported different keyboard layouts configuration and switching through the use of XKB and its database of keyboard descriptions. What we have never explicitly supported in the core desktop is input methods such as Pinyin for Chinese or the various methods to input Japanese. IBus[1] is a project that provides a framework to develop input methods with several readily available on at least Fedora and Ubuntu. This proposal aims at including explicit support for IBus in GNOME in such a way that, from the user experience point of view, choosing to use a German keyboard layout won't be that different from choosing a Korean input method. IBus is composed of several tools. Of those we are mainly interested in using the core ibus-daemon and the various engines. In particular, the goal is to not rely on its GUI tools to configure and interact with it. Instead, gnome-control-center will be the GUI to add input sources which are, for now, a simple tuple of XKB layout and IBus engine that are known to work together and which will have a UI name that is meaningful to users. gnome-shell presents the currently in use input source and the other configured ones in a status indicator and menu (what now is the keyboard status indicator). It will also present the candidates window for the input method in use, if any, based on Takao Fujiwara's work[3]. The feature wiki page[2] has some more details and links to initial code to achieve this. There's been some recent discussion wrt input methods in openSUSE: http://lists.opensuse.org/opensuse-factory/2012-05/msg00169.html Apparently, people seem to think that ibus is not the right long term solution. And fcitx has been mentioned several times, then the upstream author wrote this: http://lists.opensuse.org/opensuse-factory/2012-05/msg00205.html When reading this thread, it sounds to me that there are quite some users who are unhappy with ibus. So I'm wondering: have other approaches been considered? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applying for lockdown editor writing in GSoC
Hi, Le mercredi 04 avril 2012, à 00:25 +0300, Rūdolfs Mazurs a écrit : I think I could try to patch gnome-shell to disable workspaces and/or disable overview mode – this could be useful for a single application (kiosk) environment, where the top panel should be visible (time, volume and accessibility controls are required). Should this be done until Friday? Disabling workspaces should be rather now: it's just a matter of forcing just 1 workspace and enable support for static workspaces introduced in https://bugzilla.gnome.org/show_bug.cgi?id=671568 As to disabling the overview mode, I think that it would not be enough. If we want a single app mode for the shell, we'd also need to disable alt-f2, and every menu items that can open apps or the control center in the status icons. As well as extensions, I guess. I guess an approach could be to re-use the gdm mode in gnome-shell. Anyway, if you want to tackle this, it's best to chat with the gnome-shell people :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applying for lockdown editor writing in GSoC
Le dimanche 01 avril 2012, à 23:46 +0300, Rūdolfs Mazurs a écrit : Hello, and thanks for pointers. The information for students is lacking in the sense, that this is a new software, therefore fixing existing bugs or contributing to existing modules is problematic. Should I write something for the pessulus as it is, make some dummy application or contribute something to another project? Fixing a bug in the current pessulus is kind of useless, imho. But there are a few options: - write some small code snippets showing things that will be needed in the lockdown editor. - patch apps to make sure they respect the lockdown settings. Obviously, you need to find an app not respecting the settings first; just change an lockdown setting and check if it's respected by the apps on your desktop. Also, this is my draft of proposal (D means deliverable): First comment: there's no timeline in what you propose :-) Even if you don't have a good idea right now of what it will be, it's important to be able to show good progress at mid-term, for instance. And we can give feedback on whether your timeline is reasonable or not. 1) Understand the target audience 2) Gather requirements 2.1) Look into Pessulus features 2.2) Read Pessulus feature requests 2.3) Ask user for user input D0) List of desired features D1) Mock-up of the software, no functionality 3) Check if applications support the required lock-down features 3.1) If not, negotiate implementation with the developers D2) List of results (application support status for each feature) I would actually do this after your next step (swap 3 and 4). 4) Start implementing functionality for lock-down editor D3) First functional lock-down options 5) Write patches for other software if needed functionality is lacking D4) Full lock-down functionality 6) Write basic configuration import/export I'm not completely sure what you mean with this. Is this the full configuration? Or just lockdown? Why should it live in the lockdown editor? 7) Polish the lock-down editor (i18n, basic documentation and such) D5) Program ready for use 8) [optional] Make a configuration server and implement configuration fetching from a URL 9) Plan for expanding configuration delivery It omits any time spent learning GNOME development technologies and I am not sure about schedule. Is there anything to add? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applying for lockdown editor writing in GSoC
Hi, Le dimanche 25 mars 2012, à 19:44 +0300, Rūdolfs Mazurs a écrit : Hello all! In the list of ideas for this year's Google Summer of Code I found the suggestion to make a lockdown editor for GNOME 3. I thought I could try that. I have academic experience in writing C code and have done some Python as well. I haven't written any GTK applications so far, but I think I can learn it quickly enough. I have been using GNOME for 5 years now and have administered an Ubuntu classroom, so I believe I can understand the needs of the end user and system administrator. What I'd like to find out: * What is the required functionality of the lockdown editor? The basic features that we want is being able to lock down features that are already ready to be locked down. See for instance: http://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.desktop.lockdown.gschema.xml.in.in You can run pessulus to get an idea of how this was working for GNOME 2. Compared to the current code in pessulus, the following needs to be done: - handle GSettings settings too, not just gconf Note that lockdown is GSettings is actually handled by dconf, see https://live.gnome.org/dconf/SystemAdministrators - this first point likely involves writing a small polkit helper to actually configure the lockdown. As an example, see what was used for gconf: http://git.gnome.org/browse/gconf/tree/defaults - use pygobject with introspection for the GUI, instead of pygtk There are optional additional steps, related to making sure lockdown is properly handled by apps, or adding some additional lockdown features to GNOME. * What do I need to do to get this GSoC task? We documented this on the wiki: https://live.gnome.org/SummerOfCode2012/Students Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Last GNOME 3.4 Blocker Report
Le lundi 19 mars 2012, à 09:51 +0100, Andre Klapper a écrit : Please do speak up if some important bugs are not listed here. I'd like to add this GTK+ bug: https://bugzilla.gnome.org/show_bug.cgi?id=657385 Some change in GTK+ introspection broke the python bindings, and require an incompatible change there. Martin suggests to revert that change. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone interested in keeping pessulus alive?
Le mardi 13 mars 2012, à 09:06 +1100, Danielle Madeley a écrit : On Mon, 2012-03-12 at 08:51 -0700, Sriram Ramkrishna wrote: Pessulus was a configuration lockdown editor for GNOME 2. It never got ported to GNOME 3, as it more or less involves a complete rewrite (move to introspection-based bindings and move to GSettings) and nobody found the motivation to do so. Oh, that is just too bad. I would think that this would be useful in large installations. I hope someone take up the challenge to port it. Potential summer of code project? Makes sense, let me add the idea to the GSoC page. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone interested in keeping pessulus alive?
Le lundi 12 mars 2012, à 17:39 -0600, Federico Mena Quintero a écrit : On Mon, 2012-03-12 at 14:00 +0100, Vincent Untz wrote: Pessulus was a configuration lockdown editor for GNOME 2. It never got ported to GNOME 3, as it more or less involves a complete rewrite (move to introspection-based bindings and move to GSettings) and nobody found the motivation to do so. Unless someone steps up within a week to become maintainer, I'll move pessulus to our archives. Another thing is that Gnome 3 provides different configuration keys than Gnome 2 - gnome-shell and friends are completely different beasts. I'm sure we'd need to implement lockdown-friendly keys in Gnome 3 for things that are missing. To be fair, we didn't have very good keys either in GNOME 2 ;-) Now, we have the org.gnome.desktop.lockdown GSettings keys, but I've no idea if apps respect those... Archive it away, I'd say... since you are the maintainer, do you remember anything particularly interesting/tricky in the implementation of Pessulus that may be useful to implementors of similar stuff for Gnome 3? There was nothing really tricky in pessulus itself, except knowing which keys exist and finding how to present them (and even for that, I don't think we were doing such a great job :/). But the real tricky part is to add more lockdown features to GNOME and make sure those are respected. (Sabayon is in a similar situation - it's just not useful for Gnome 3. If you archive Pessulus, would you be able to move Sabayon as well in exchange for a promise of beer?) I was also wondering about the state of sabayon. Does it make sense to also see if a GSoC student want to save it before archiving it? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone interested in keeping pessulus alive?
Le mardi 13 mars 2012, à 10:11 -0400, Colin Walters a écrit : On Mon, 2012-03-12 at 14:00 +0100, Vincent Untz wrote: Hi, Pessulus was a configuration lockdown editor for GNOME 2. It never got ported to GNOME 3, as it more or less involves a complete rewrite (move to introspection-based bindings and move to GSettings) and nobody found the motivation to do so. Hm, but we haven't removed pygtk and GConf (as far as I know). So the issue is more that it doesn't know how to lock down GNOME 3? Or are we missing equivalent keys? Or are we just saying it should be archived because it uses deprecated functionality? Or some mix of this? I guess the question is - is it really totally worthless right now? It is totally worthless because it works on GConf keys that either don't exist anymore (for some apps, like epiphany, gnome-panel, etc.) or that are ignored by apps now (lockdown keys from libgnome). Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Anyone interested in keeping pessulus alive?
Hi, Pessulus was a configuration lockdown editor for GNOME 2. It never got ported to GNOME 3, as it more or less involves a complete rewrite (move to introspection-based bindings and move to GSettings) and nobody found the motivation to do so. Unless someone steps up within a week to become maintainer, I'll move pessulus to our archives. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.4 Blocker Report
Le vendredi 09 mars 2012, à 12:50 +0100, Andre Klapper a écrit : === GNOME-SESSION === fail whale extension list looks bad https://bugzilla.gnome.org/show_bug.cgi?id=671693 Needs more information and testing. I don't think it's a blocker, and we're past the freeze to change the UI there. [PATCH] Need signal matching Setenv dbus method so apps in initialization phase can update their env too https://bugzilla.gnome.org/show_bug.cgi?id=662528 Five patches available awaiting review for two months now Patches don't work, as mentioned by Cosimo in a comment. There is discussion on using another approach too. It's highly annoying for technical users so blocker, indeed. gnome-session no longer starts desktop files under /usr/share/gdm/autostart/LoginWindow https://bugzilla.gnome.org/show_bug.cgi?id=663721 Inline patch that needs more work available Not sure why this is a blocker? Certainly a valid bug we should get fixed, though. fail whale triggers too easily https://bugzilla.gnome.org/show_bug.cgi?id=671694 This used to work fine (I think Colin had fixed a similar issue a while ago, but I could be wrong). Did something change on gnome-shell's side, when it's being restarted? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.4 Blocker Report
Le vendredi 09 mars 2012, à 11:29 -0500, Matthias Clasen a écrit : On Fri, Mar 9, 2012 at 7:53 AM, Vincent Untz vu...@gnome.org wrote: Le vendredi 09 mars 2012, à 12:50 +0100, Andre Klapper a écrit : === GNOME-SESSION === fail whale extension list looks bad https://bugzilla.gnome.org/show_bug.cgi?id=671693 Needs more information and testing. I don't think it's a blocker, and we're past the freeze to change the UI there. I don't really see how the fail whale would be particularly affected by the ui freeze. There might be documentation mentioning it, so that it's not just the horrible death dialog that nobody explains anywhere. I expect people to look for more information about that kind of dialogs either on next login, or thanks to another device while it's on screen. The current screen looks _really_ bad... It didn't look that bad last time I got it (with 3.3.5?). I'll try with latest code of everything. Vincent -- Les gens heureux ne sont pas pressés. ___ 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
Hi, Le samedi 28 janvier 2012, à 12:54 -0500, Colin Walters a écrit : On Sat, 2012-01-28 at 17:34 +, Bastien Nocera wrote: I don't think Vincent was surprised, or he really shouldn't have been: https://bugzilla.gnome.org/show_bug.cgi?id=654970#c2 https://bugzilla.gnome.org/show_bug.cgi?id=654970#c3 For reference, I'm not surprised it went away; I'm surprised it went away now, without any announcement. [...] Anyways I don't think we're in violent disagreement here, and what I want to focus on is concrete actions. Vincent, Michael, Milan, as the people who actually contributed code here - are you guys OK with the DBus backend work and/or future plans to use systemd? I've already mentioned earlier I'm fine with plans to use systemd, my main worry being a smooth transition. For reference, one issue people might have with this change, even for people extracting the code of timedated from systemd, is that querying the state of ntp and enabling/disabling ntp requires systemd -- since it's all done via dbus methods of the systemd service. Now, I do believe that's actually a good thing since it means there's no need for custom code for each distro. And I'm fine with it for openSUSE: that's something I'm ready to lose for users not booting with systemd (even better if g-c-c doesn't show the ntp toggle when this happens). Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: --enable-systemd and sysvinit fallback (was: datetime: Remove datetime D-Bus mechanism)
Le mardi 24 janvier 2012, à 15:59 +0100, Olav Vitters a écrit : On Mon, Jan 23, 2012 at 03:31:29PM +0100, Olav Vitters wrote: On Mon, Jan 23, 2012 at 03:03:36PM +0100, Vincent Untz wrote: Another systemd-related change was already mentioned earlier: the new --enable-systemd configure flag that removes ConsoleKit support when it's used. It cannot really be used for openSUSE (and Mageia, I'd say). I want to thank Matthias for his extra effort of reworking the gnome-session patch after my concern, though. I have notified Mageia of --enable-systemd a while ago, but didn't discuss it yet. I know Mageia will be full systemd only in version 3, but not sure regarding version 2. I haven't made my mind up regarding version 2, perhaps easier to just rely on ConsoleKit in v2, then --enable-systemd in version 3. Leaning to not think and fully let the other people at Mageia investigate. I've sent a mail (perhaps badly summarized the status) to Mageia, and outcome is that we'll not use --enable-systemd during Mageia 2. What will openSUSE do? This so I can write a proper announcement to distributor-list :) For openSUSE 12.2, the --enable-systemd option will only be used if it doesn't introduce a loss of features, or regressions when the system is not booted with systemd. No idea about 12.3 yet, it's too far away. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ 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
Hi, Le lundi 23 janvier 2012, à 13:02 +0100, Olav Vitters a écrit : On Mon, Jan 23, 2012 at 10:54:30AM +0100, Frederic Crozat wrote: 2012/1/23 Olav Vitters o...@vitters.nl: On Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. Or maybe people aren't very happy of the tone of the discussion and don't want to be dragged into it (and that is why I didn't reply when openSUSE was mentioned). For reference, I feel the same. I originally wanted to reply to the thread, but got distracted. When I came back to it, it was full of negative comments, bad feelings, etc. And I'm tired of the bad atmosphere on d-d-l. FWIW, here's what I wanted to say at first: in openSUSE, we're not affected as downstream, but as this mechanism could be considered as a public API, I'd have preferred to learn about the change a bit earlier to check it's all fine for us (and yes, I understand it's not always possible). With my upstream hat: I think we could keep this for one cycle and mention somewhere in NEWS that it's deprecated and will disappear in the next cycle. It doesn't cost us much to do that, and it's nice to our downstreams. [...] This change is also problematic for people who might not be using the last version of their distribution or who have issue with systemd which aren't fixed yet and are forced to use sysvinit. Mageia 2 will have an optional sysvinit (default is systemd). I don't really see the problem for Mageia. In case of sysvinit, some minor stuff might not work or might not work (perhaps daemons would still work under sysvinit, don't care). For me, if you choose the fallback, don't expect things to work perfectly. Is this the openSUSE viewpoint? This is similar to what we're doing for openSUSE. Still, I think it's better to nicely handle the case where systemd is not what is being used. It enables a smoother migration. Another systemd-related change was already mentioned earlier: the new --enable-systemd configure flag that removes ConsoleKit support when it's used. It cannot really be used for openSUSE (and Mageia, I'd say). I want to thank Matthias for his extra effort of reworking the gnome-session patch after my concern, though. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting all windows title
Le vendredi 16 décembre 2011, à 13:56 -0500, Leonel Florin Selles a écrit : Hi, I'm trying to get all the title of the opened windows on a Gnome Desktop, for that I want to use C++, there is a way? Here's some code that does exactly this: http://developer.gnome.org/libwnck/stable/getting-started.html#getting-started.examples Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Le mercredi 30 novembre 2011, à 10:31 +0100, William Jon McCann a écrit : Hi, On Wed, Nov 30, 2011 at 8:08 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 30 novembre 2011, à 00:37 +0200, Zeeshan Ali (Khattak) a écrit : Hi everyone, As most of you know, we proposed Boxes for 3.4 and from what I can tell, there were no big objections in the end. There was then the question of us actually delivering in time. As seen on planet GNOME not long after that, we delivered the first release which was included in 3.3.2. There is still a long way ahead to make Boxes the awesome app that we all would like it to be but to ensure that Boxes is in good enough shape for 3.4 inclusion in time, we would like to know a few things: * which features exactly are must? * is the plan to keep vinagre in 3.4 alongside boxes? * is Boxes going to be a 'preview' feature in 3.4 like Documents was in 3.2? Release team? everyone? I'm sorry, but I still have the same objection :-) And talking to a few people, I understood that I'm not alone in feeling that Boxes might not fit core GNOME (even as a core app [1]). Can you be more specific about the reasons for your objection? As mentioned in the previous thread: I don't think Boxes is needed for what is our main target audience. And let me state again that it is a nice tool for a small part of our users (including our own community). Do you feel the same way about Vinagre? To me, the main use case of Vinagre is remote desktop administration, when coupled with Vino. And that's actually why we added vino in 2.8 (to help sysadmins help users), and then vinagre in 2.22 (nice complement to vino). The vino/vinagre duo is/was oriented towards sysadmins (although it could be used for other use cases). [1] http://live.gnome.org/Design/Apps -- just to give an example: I feel that a backup tool makes more sense than boxes as a core app, imho. And the wiki says that such a tool is very likely not a core app but would make a great regular app. Really, this shouldn't be a competition between Backup and Boxes. This is not a competition. This was just an example to help show why I feel Boxes doesn't fit in that category. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Le mercredi 30 novembre 2011, à 12:33 +0100, William Jon McCann a écrit : On Wed, Nov 30, 2011 at 12:26 PM, Vincent Untz vu...@gnome.org wrote: Le mercredi 30 novembre 2011, à 10:31 +0100, William Jon McCann a écrit : Hi, On Wed, Nov 30, 2011 at 8:08 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 30 novembre 2011, à 00:37 +0200, Zeeshan Ali (Khattak) a écrit : Hi everyone, As most of you know, we proposed Boxes for 3.4 and from what I can tell, there were no big objections in the end. There was then the question of us actually delivering in time. As seen on planet GNOME not long after that, we delivered the first release which was included in 3.3.2. There is still a long way ahead to make Boxes the awesome app that we all would like it to be but to ensure that Boxes is in good enough shape for 3.4 inclusion in time, we would like to know a few things: * which features exactly are must? * is the plan to keep vinagre in 3.4 alongside boxes? * is Boxes going to be a 'preview' feature in 3.4 like Documents was in 3.2? Release team? everyone? I'm sorry, but I still have the same objection :-) And talking to a few people, I understood that I'm not alone in feeling that Boxes might not fit core GNOME (even as a core app [1]). Can you be more specific about the reasons for your objection? As mentioned in the previous thread: I don't think Boxes is needed for what is our main target audience. And let me state again that it is a nice tool for a small part of our users (including our own community). The only thing you mentioned in the other thread that I saw was a feeling that it wasn't right. I said that I didn't feel Boxes should be tracked as a feature, and that I didn't believe it was useful to most users. Can you explain why you don't think it is useful and for what audience? Just to clarify: I didn't say it is not useful. I even said it's something that is essential to some users. Boxes is great for software developers, contributors to GNOME distros, and technology enthusiasts. Those are all people we care deeply about, but I don't believe they represent such a high percentage of our users (or of all users we'd like to have). And we can (and should) deliver and promote Boxes to the developers, contributors and enthusiasts without having Boxes part of the core. Do you feel the same way about Vinagre? To me, the main use case of Vinagre is remote desktop administration, when coupled with Vino. And that's actually why we added vino in 2.8 (to help sysadmins help users), and then vinagre in 2.22 (nice complement to vino). The vino/vinagre duo is/was oriented towards sysadmins (although it could be used for other use cases). Do you think these should not be part of the GNOME core? I think vino should stay as a desktop service, but vinagre could potentially go as an app that is not part of core. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Le mercredi 30 novembre 2011, à 00:37 +0200, Zeeshan Ali (Khattak) a écrit : Hi everyone, As most of you know, we proposed Boxes for 3.4 and from what I can tell, there were no big objections in the end. There was then the question of us actually delivering in time. As seen on planet GNOME not long after that, we delivered the first release which was included in 3.3.2. There is still a long way ahead to make Boxes the awesome app that we all would like it to be but to ensure that Boxes is in good enough shape for 3.4 inclusion in time, we would like to know a few things: * which features exactly are must? * is the plan to keep vinagre in 3.4 alongside boxes? * is Boxes going to be a 'preview' feature in 3.4 like Documents was in 3.2? Release team? everyone? I'm sorry, but I still have the same objection :-) And talking to a few people, I understood that I'm not alone in feeling that Boxes might not fit core GNOME (even as a core app [1]). Note that this shouldn't actually block any work on Boxes, as it does look like a great application. Vincent [1] http://live.gnome.org/Design/Apps -- just to give an example: I feel that a backup tool makes more sense than boxes as a core app, imho. And the wiki says that such a tool is very likely not a core app but would make a great regular app. -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New desktop help system ?
Le jeudi 24 novembre 2011, à 10:23 -0500, Shaun McCance a écrit : On Thu, 2011-11-24 at 11:48 +0100, Pierre Wieser wrote: Hi, As I was googling searching why the help is not displayed for my application, I have found [1], which states: The desktop help has moved to the new proposed XDG help system [...] Though I read both desktop-devel and xdg lists, I do not remember anything recent on the subject, and Google has not been my friend in this matter. Could someone give me some pointers, please ? What is this help system ? Where is the XDG spec ? and so on...:) The spec can be found in the xdg-specs repository: http://cgit.freedesktop.org/xdg/xdg-specs/tree/help-system I don't think it was ever published as HTML on freedesktkop.org, unfortunately. Want me to do it? If yes, what version should I use? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes (was Re: 3.4 Features, final round)
Le lundi 07 novembre 2011, à 20:21 +0100, Zeeshan Ali (Khattak) a écrit : On Mon, Nov 7, 2011 at 9:00 AM, Vincent Untz vu...@gnome.org wrote: Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit : + Boxes https://live.gnome.org/ThreePointThree/Features/Boxes → many commits, mclasen will push the developers to blog a progress report once they have something to show While Boxes look interesting, to me, it feels like it's just an application, and not a feature per se. And I'm not saying that in a negative way :-) You are correct in the sense that it is 'an' application and not 'a' feature. It is more like 2 essential features combined in one: 1. Remote display: It is very common to own/having to deal with multiple machines these days so many users really need ability to easily connect to remote machines (virtual and real). 2. Trying out OSs: Each time we release GNOME, I really want to try it out and I know many people who do. Same goes for distros but people usually try to avoid risks and therefore most people wait till the OS in question is stable enough. I have even seen people avoid trying out an OS just because they are too scared of it doing any harm to their computers. Users will definitely appreciate an easy and completely secure way to try out OSs. I think these features are very essential and therefore should be available in every GNOME installation out of the box. They are very essential to some users, but not to most users. Don't get me wrong, I'll most probably be one big (hopefully happy ;-)) user of Boxes. I just don't think that considering it as a feature is the right way to integrate it in our development process. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Boxes (was Re: 3.4 Features, final round)
Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit : + Boxes https://live.gnome.org/ThreePointThree/Features/Boxes → many commits, mclasen will push the developers to blog a progress report once they have something to show While Boxes look interesting, to me, it feels like it's just an application, and not a feature per se. And I'm not saying that in a negative way :-) So unless I'm missing something, I wouldn't track that as a 3.4 feature. We can of course talk about the app when promoting 3.4, though. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
Le mercredi 28 septembre 2011, à 14:35 -0400, Cosimo Cecchi a écrit : Also, gnome-utils has the same unrelated tags issue of gdk-pixbuf, so they would need to be manually selected anyway (unless we also want to keep things tags like DROOLING_MACAQUE and PANTING_CHIMPANZEE...seriously, I feel like I'm missing all the fun! :P) Are you seriously considering dropping tags with such cool names? Man, I won't talk to you anymore -- ever. ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switch of GNOME tarball compression format: tar.xz only
Le dimanche 11 septembre 2011, à 13:41 +0200, Olav Vitters a écrit : If you have concerns, I'd like to hear about it. I've set the reply-to to desktop-devel-list and distributor-list. With a few other (non-gnome) tarballs switching to xz-only, one thing I realized is that python doesn't support that yet: http://bugs.python.org/issue6715 It means that, for my downstream activities, I'll have to update some scripts to work around this missing feature in python. It's not a blocker for the switch (at least for me), but that might be something others need to consider. Note that there's been some recent activity in the python bug, so maybe that won't be an issue at all. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Le vendredi 09 septembre 2011, à 13:09 +0100, Javier Jardón a écrit : Hi all, As you can read in the Ryan blog post [1], the use of the AM_MAINTAINER_MODE macro is only correct when used in this way: AM_MAINTAINER_MODE([enable]) As ryan said in the blog post, fredp made a report page for packages using AM_MAINTAINER_MODE. green - no “AM_MAINTAINER_MODE” at all (good) yellow - “AM_MAINTAINER_MODE([enable])” (fine) orange - means that your package is currently broken and needs to be fixed. So if Its not already fixed in your module, we are going to proced to fix all the GNOME modules that appear in orange and convert it to yellow, ie AM_MAINTAINER_MODE - AM_MAINTAINER_MODE([enable]) Thanks for you collaboration. I'd prefer to get https://bugzilla.gnome.org/show_bug.cgi?id=658608 fixed, instead of adding back AM_MAINTAINER_MODE in my modules. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Le vendredi 09 septembre 2011, à 13:49 +0100, Javier Jardón a écrit : On 9 September 2011 13:24, Vincent Untz vu...@gnome.org wrote: Le vendredi 09 septembre 2011, à 13:09 +0100, Javier Jardón a écrit : Hi all, As you can read in the Ryan blog post [1], the use of the AM_MAINTAINER_MODE macro is only correct when used in this way: AM_MAINTAINER_MODE([enable]) As ryan said in the blog post, fredp made a report page for packages using AM_MAINTAINER_MODE. green - no “AM_MAINTAINER_MODE” at all (good) yellow - “AM_MAINTAINER_MODE([enable])” (fine) orange - means that your package is currently broken and needs to be fixed. So if Its not already fixed in your module, we are going to proced to fix all the GNOME modules that appear in orange and convert it to yellow, ie AM_MAINTAINER_MODE - AM_MAINTAINER_MODE([enable]) Thanks for you collaboration. I'd prefer to get https://bugzilla.gnome.org/show_bug.cgi?id=658608 fixed, instead of adding back AM_MAINTAINER_MODE in my modules. We are not going to modify the modules that are not using AM_MAINTAINER_MODE at all (green). We are only going to change the modules that are using AM_MAINTAINER_MODE (orange) to AM_MAINTAINER_MODE([enable]) Also, that bug is unrelated with the use of AM_MAINTAINER_MODE Sorry, you're wrong :-) gnome-session is orange in the report and doesn't use AM_MAINTAINER_MODE. And that's because it uses the GNOME_MAINTAINER_MODE_DEFINES macro, which has: AC_REQUIRE([AM_MAINTAINER_MODE]) This is what Ryan wanted to fix in the bug above :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 Blocker Report for week 35
Le jeudi 01 septembre 2011, à 18:50 +0200, Andre Klapper a écrit : gnome-menus: Tools to perform system administration should be available in the menus somehow https://bugzilla.gnome.org/show_bug.cgi?id=645061 Patches available in the report. (Note that the tools are available in the Other category right now, so I'm not sure this is a blocker by itself) The current suggestion is to add a Settings category in the menus; however, I'm unsure how well this works with the fact that it won't show what's in the gnome-control-center... Any opinion? The alternative is to just leave Other, and push people to move the items there in more appropriate categories. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-menus API changes
Hi, In the past few months, Colin reworked the gnome-menus API to bring various improvements. The most visible part is that the menu entries are now based on GDesktopAppInfo, and that we now have real introspection support. You can see some of the discussion at https://bugzilla.gnome.org/show_bug.cgi?id=647968 We're now merging this so that it will be part of 3.1.5. We're also merging the appropriate patches to port gnome-control-center, gnome-panel and gnome-shell. If you build from source, this means you'll need to rebuild those four components. Note that the new code is parallel-installable, so the old library can still be used. It is needed for alacarte, at least (which needs to be ported to pygi); I'm not aware of any other module that needs to be ported, but if you're impacted, just ask and we can help. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Archiving old non-maintained (for GNOME 3) applets
Le vendredi 10 juin 2011, à 12:07 +0200, Vincent Untz a écrit : So far, I only have this small list: bookmark-applet contact-lookup-applet deskbar-applet gnome-netstatus It also appears that libpanelappletmm won't get ported (and the gnote developers decided to directly use the C library instead for the GNOME 3 port). So unless anybody complains about those 5 modules, I'll file a bug to get them archived. No objection = I filed https://bugzilla.gnome.org/show_bug.cgi?id=654234 Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
Le vendredi 01 juillet 2011, à 14:17 +0100, Ross Burton a écrit : On 1 July 2011 13:56, Ross Burton r...@burtonini.com wrote: If you intend this to be part of 3.1.3, merging it before the weekend would be nice. That will give us a few more days to deal with possible fallout and find a volunteer to roll a gconf tarball. Okay, I've just merged it to master. As I said it defaults to using ORBit so hopefully this is a no-op for most people. Please report any breakage to me! So what's the recommendation for downstreams? :-) Should we try to switch to the dbus port, or stay with the old stuff? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Archiving old non-maintained (for GNOME 3) applets
Hi, I guess everyone knows that GNOME 2 applets don't work in GNOME 3, and talking here and there, the feedback I got is that it wasn't worth creating a bridge to be able to load those in the GNOME 3 panel. As several applets are not going to be ported to GNOME 3 (either because the code is unmaintained or it has been announced already), I think we should clearly archive them so that translators stop working on them and distributors know their status. So far, I only have this small list: bookmark-applet contact-lookup-applet deskbar-applet gnome-netstatus It also appears that libpanelappletmm won't get ported (and the gnote developers decided to directly use the C library instead for the GNOME 3 port). So unless anybody complains about those 5 modules, I'll file a bug to get them archived. Is there any other git module for an applet that we should archive? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ 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
Le mercredi 01 juin 2011, à 13:33 +0100, Richard Hughes a écrit : On 1 June 2011 12:57, Matthias Clasen matthias.cla...@gmail.com wrote: Basically, mailing lists don't work for many kinds of productive discussion. Agreed. In my recent discussions with the dudes in #gnome-design there was a flurry of messages, perhaps as many as 200 back-and-forth discussions per hour. In that same hour, we iterated about 20 screenshots and quite a few designers piled in with suggestions. You just can't get that kind of latency and interest level with a mailing list. One thing that could be improved with mails, though, is communication about the design after the iterative process on IRC you describe. Many people would love to have a summary of the rationale of the design. I'm aware this is sometimes (maybe even always) propagated to a wiki page. But people still won't know about the wiki page if there's no announcement about it. (fwiw, I pretty much agree that defining a design on a mailing list doesn't work well) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le mercredi 18 mai 2011, à 19:08 +0200, Johannes Schmid a écrit : Hi! Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. I think Lennart made the point that systemd is not portable and won't be ported. He also made the point that that doesn't mean other OS could share the same interfaces as systemd while providing a completely different backend and he also made clear that the parts GNOME will likely depend on apart from gdm will be buildable on any OS while not providing much use. Oh yes, I'm not saying systemd should be ported to the non-Linux world; that's why I even mentioned the high cost for it in my mail. Sharing interfaces makes sense in that case. I really don't think we can make a useful control-center that supports all kind of operating systems. People that care about configuring OS parts on non-linux systems should probably write their own control-center. Two things here: - if we share interfaces, as suggested several times, surely we can have one control-center for many OS. Those OS just need to implement the interfaces. - I don't think all system settings panels need deep integration with the OS, so there's no need to build a completely different control-center for non-linux systems. We can disable some panels on some OS if needed. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
Le mercredi 20 avril 2011, à 19:12 -0400, Colin Walters a écrit : One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. Why do we need to address this? Aren't we happy letting developers choose the language they are the most comfortable with? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SoC idea: desktop file cache
Le vendredi 25 mars 2011, à 21:52 +, Bastien Nocera a écrit : On Sat, 2011-03-26 at 03:11 +0530, Nirbheek Chauhan wrote: snip I was thinking that this is the kind of problem that has cross-desktop implications, and so I wondered how KDE solves this problem. We should probably take their feedback on this? On the other hand, I think there is a way to do this in a cross-desktop fashion with existing infrastructure as well. We already have `update-desktop-database` for updating the MimeType cache from desktop files, and that's supposed to be run after any new .desktop files are added to $XDG_DATA_DIRS/applications, so I was wondering if caches for the other properties could also be generated by the same tool at the same time? I wouldn't want the code to live in update-desktop-database (which is in shared-mime-info), but we can certainly add support for launching scripts in a specific directory whenever it's called. It's actually in desktop-file-utils, not shared-mime-info :-) Any reason you wouldn't want to add that to the utility? Or was it just that you thought it lived in shared-mime-info which shouldn't know about that kind of stuff? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SoC idea: desktop file cache
Le jeudi 24 mars 2011, à 23:22 -0400, Colin Walters a écrit : == Kill gnome-menus == gnome-menus is the library which reads all this stuff presently, and it has one serious drawback: * It is entirely synchronous This especially hurts since we have to read applications from gnome-shell, which is the compositor - a blocked compositor means no redrawing. [...] == Implementing a saner tool == There are multiple ways to approach this, but I think by far the simplest is just an mmap'able file containing all .desktop files found in the desktop paths. Don't try to implement all the merge logic, etc. But we still want the merge logic to build menus. So it sounds to me that what you want is to make gnome-menus use a mmaped file. And we should also fix the other gnome-menus issues; I'm very much aware of them and would also love them to disappear). Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for Summer of Code ideas
Hi all, Good news: GNOME has been accepted as a mentoring organization for GSoC 2011, woo :-) If you want to be a mentor, please apply with the following form: http://www.google-melange.com/gsoc/mentor/request/google/gsoc2011/gnome Also, it's not too late to add ideas to the wiki page, see Christophe's mail below. I'm sure we can have many more GNOME 3-related ideas! Cheers, Vincent Le lundi 07 mars 2011, à 11:27 +0100, Christophe Fergeau a écrit : Hiya GNOME lovers! It's that time of the year again: Google's Summer of Code is approaching. We are in the midst of preparing it all [1] but we need your help by submitting great project ideas. Student proposals will start to roll in on March 28, but we'd like to make sure there are plenty of projects from them to choose from and have mentors ready to volunteer their time. So what should you do? Please visit [2] and enter your project ideas under the Other Ideas section. A committee will be formed up later to triage the ideas prior to the opening of the proposal period. If you would like to volunteer your time to mentor but don't have a project idea, surf over and claim one. Mentoring is an awesome way to get more involved with the community and introduce someone to it. If you would like to throw your hat in the ring for the triaging or selection committees and other GSoC related tasks, pop on over to #soc-admin, join the soc-mentors-list and let one of the administrators for the program know you want to be involved in making GNOME rock. This year's administrators are Vincent Untz, Ruben Vermeersch, Christophe Fergeau and Daniel Siegel. Cheers, The GNOME Google Summer of Code Administrators [1] http://live.gnome.org/SummerOfCode2011 [2] http://live.gnome.org/SummerOfCode2011/Ideas -- devel-announce-list mailing list devel-announce-l...@gnome.org http://mail.gnome.org/mailman/listinfo/devel-announce-list -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no way to change theme or fonts in System Settings?
Le mercredi 16 mars 2011, à 19:31 -0700, Adam Dingle a écrit : In the current GNOME 3 build the System Settings application doesn't seem to give me any way to change my fonts or theme. This seems like a significant regression from the previous Control Center, which offered the Appearance applet for this purpose. Was theme/font configuration removed intentionally? Or is it planned, but there simply hasn't been time to implement this in System Settings yet? Will there be any way a user can configure these through the GUI in GNOME 3.0? There'll be a tool for that, although that is an add-on tool (ie, not part of the control center). Since I've been lagging on this, John Stowers stepped up and moved much faster than I did (he also chose python while I was playing with js ;-)): https://github.com/nzjrs/gnome-tweak-tool (kudos to John!) This needs some love, and we'll import that in git.gnome.org, I assume. But yeah, that's how we will deal with this :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: install-module / ftp.gnome.org / master.gnome.org
Hey, Le mercredi 02 mars 2011, à 11:50 +0100, Olav Vitters a écrit : == A. diff/delta files between versions == I don't know of anybody using this to update from a tarball to a newer one. However, I guess some people use this to quickly see what has changed between the two tarballs. I don't think this use case is covered by the xdelta3 thing. Maybe it's not a big loss, though? == B. What kind of compression should be used for tarballs? == Currently we use 'gz' and 'bzip2'. Last time it was asked (lots of years ago), there was a mention that not everyone has 'bzip2'. I'd like to: - 'Kill .gz'[3] - Introduce some kind of lzma type compression Pretty every distribution released over the last few years has support for this. Further, http://www.7-zip.org/ has support for this on Windows. Conversion might take a while on master.gnome.org, but seems manageable. Not sure if I can easily combine lzma and xdelta3. Hrm, I wouldn't change past releases. Just leave them the way they are; it shouldn't hurt. - Ideally only have one compression type on ftp.gnome.org We have enough disk space, but I still don't want to waste it if there is no need. Additionally, minimizing disk usage speeds up backups. I believe that Debian still uses .gz for the upstream tarball, and at least in openSUSE, we generally use .bz2 for upstream tarballs (I guess it's okay to switch to lzma for openSUSE, though). By forcing downstreams to recompress, we lose the ability to compare the checksums between upstream and downstream. Not critical, but it was something nice. Also, there might be tools used by various people that need to be updated -- not an issue, but this means we'll want to properly announce the change. For the rest, I guess it's mostly a matter of habits... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: install-module / ftp.gnome.org / master.gnome.org
Le mercredi 02 mars 2011, à 12:47 +0100, Olav Vitters a écrit : On Wed, Mar 02, 2011 at 12:10:09PM +0100, Vincent Untz wrote: Conversion might take a while on master.gnome.org, but seems manageable. Not sure if I can easily combine lzma and xdelta3. Hrm, I wouldn't change past releases. Just leave them the way they are; it shouldn't hurt. Oh, actually I didn't want to change existing files. I meant conversion when someone provides a tar.gz and then generating a .tar.lzma (or .tar.xv). Same as currently is done for .tar.bz2. The lzma compression time is much more noticeable than bz2. First step: kindly ask maintainers to use dist-lzma in AM_INIT_AUTOMAKE ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-session] rename gnome-session-save to gnome-session-quit
Hi,
(I don't want to pick on Jon here; that's just the latest commit like
this one)
I would appreciate if patches could get posted on bugzilla for review,
instead of being committed directly without asking maintainers. I know
I'm not the fastest reviewer out there, but as I've told several times
before, if you think the patch is important and doesn't get a review
before the next release, then it's welcome to push the patch.
In this case, the patch is mostly good, but the man page is wrong
(--logout is the default behavior, but it's not mentioned and it's
unclear what happens by default; --no-prompt doesn't do anything with
--power-off).
Vincent
Le jeudi 24 février 2011, à 22:56 +, William Jon McCann a écrit :
commit 8663860ff44b9a5e441e4909a49eee4cfa08378d
Author: William Jon McCann jmcc...@redhat.com
Date: Thu Feb 24 17:38:13 2011 -0500
rename gnome-session-save to gnome-session-quit
Is much less misleading since it doesn't save anything.
doc/man/Makefile.am|2 +-
doc/man/gnome-session-quit.1 | 25
doc/man/gnome-session-save.1 | 40 ---
po/POTFILES.in |2 +-
tools/Makefile.am | 10 +-
.../{gnome-session-save.c = gnome-session-quit.c} | 116 +++
6 files changed, 51 insertions(+), 144 deletions(-)
---
diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am
index 72f9a93..e42430a 100644
--- a/doc/man/Makefile.am
+++ b/doc/man/Makefile.am
@@ -1,7 +1,7 @@
man_MANS = \
gnome-session.1 \
gnome-session-properties.1 \
- gnome-session-save.1
+ gnome-session-quit.1
EXTRA_DIST = \
$(man_MANS)
diff --git a/doc/man/gnome-session-quit.1 b/doc/man/gnome-session-quit.1
new file mode 100644
index 000..2f6df84
--- /dev/null
+++ b/doc/man/gnome-session-quit.1
@@ -0,0 +1,25 @@
+.\
+.\ gnome-session-quit manual page.
+.\ (C) 2000 Miguel de Icaza (mig...@helixcode.com)
+.\ (C) 2009-2010 Vincent Untz (vu...@gnome.org)
+.\
+.TH GNOME-SESSION-QUIT 1 GNOME
+.SH NAME
+gnome-session-quit \- End the current GNOME session
+.SH SYNOPSIS
+.B gnome-session-quit [\-\-logout] [\-\-power-off] [\-\-no-prompt]
+.SH DESCRIPTION
+The \fIgnome-session-quit\fP program can be used to end a GNOME session.
+.PP
+If called with the \fB\-\-logout\fP option the user will be prompted
+to confirm logout. The \fB\-\-no\-prompt\fP option can be used to end
+the session without user interaction.
+.PP
+When the \fB\-\-power\-off\fP option is given the user will be
+prompted to confirm system power off. The \fB\-\-no\-prompt\fP option
+can be used to power off without user interaction.
+.SH BUGS
+If you find bugs in the \fIgnome-session-quit\fP program, please report
+these on https://bugzilla.gnome.org.
+.SH SEE ALSO
+.BR gnome-session(1)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 4b3a1a1..1e7491d 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -20,4 +20,4 @@ gnome-session/gsm-xsmp-client.c
gnome-session/gsm-xsmp-server.c
gnome-session/gsm-util.c
gnome-session/main.c
-tools/gnome-session-save.c
+tools/gnome-session-quit.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index fbc41b5..f53a012 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -1,14 +1,14 @@
-bin_PROGRAMS = gnome-session-save
+bin_PROGRAMS = gnome-session-quit
libexec_PROGRAMS = gnome-session-is-accelerated
AM_CPPFLAGS =
AM_CFLAGS = $(WARN_CFLAGS)
-gnome_session_save_SOURCES = \
- gnome-session-save.c
+gnome_session_quit_SOURCES = \
+ gnome-session-quit.c
-gnome_session_save_CPPFLAGS =\
+gnome_session_quit_CPPFLAGS =\
$(AM_CPPFLAGS) \
$(GNOME_SESSION_CFLAGS) \
$(DBUS_GLIB_CFLAGS) \
@@ -16,7 +16,7 @@ gnome_session_save_CPPFLAGS = \
-DLOCALE_DIR=\$(datadir)/locale\\
$(DISABLE_DEPRECATED_CFLAGS)
-gnome_session_save_LDADD = \
+gnome_session_quit_LDADD = \
$(SM_LIBS) \
$(ICE_LIBS) \
$(GNOME_SESSION_LIBS) \
diff --git a/tools/gnome-session-save.c b/tools/gnome-session-quit.c
similarity index 59%
rename from tools/gnome-session-save.c
rename to tools/gnome-session-quit.c
index 28f6443..f5d1838 100644
--- a/tools/gnome-session-save.c
+++ b/tools/gnome-session-quit.c
@@ -43,54 +43,23 @@ enum {
GSM_LOGOUT_MODE_FORCE
};
-/* True if killing. This is deprecated, but we keep it for compatibility
- * reasons. */
-static gboolean kill_session = FALSE;
-
-/* The real options that should be used now
Re: [gnome-session] rename gnome-session-save to gnome-session-quit
Le lundi 28 février 2011, à 08:25 -0500, William Jon McCann a écrit : Hi Vincent, I wrote most of gnome-session and am still listed as a maintainer. Actually, Dan wrote most of the new gnome-session ;-) And I'm sorry, but with two commits in 2011, two commits in 2010 and 10 commits in 2009 (9 of them were in January), I don't consider you as an active maintainer of gnome-session. Don't get me wrong: I do appreciate the patch, I do appreciate what you brought to gnome-session in the past, I do want you to keep patchin gnome-session. And I'm happy with this specific change. Except that it's not 100% right, as a review by a maintainer would have shown. Also, as I wrote, it's not about you specifically, I've seen this from several people. So, I'm not sure what the problem is. I agree in principle with using code review which is why I asked a few people to look the patch over for me. Did you ask the other maintainers? This is crunch time man. It is all about getting it done. Sure, I agree, which is why I don't block anybody from pushing commits if there was no review in bugzilla after a while. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-session] rename gnome-session-save to gnome-session-quit
Le lundi 28 février 2011, à 14:53 +0100, Vincent Untz a écrit : Also, as I wrote, it's not about you specifically, I've seen this from several people. Just to make it extremely clear: this is the issue I have. If people want to step up and become co-maintainers of my modules, then please state so. I'll generally be happy to have less maintainer hats. Let me apologize to Jon -- it was not my intention to put him under a bad light for this commit; his commit was simply the last one highlighting a more generic issue. And it was probably not the best example as his commit was mostly right. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.90 build issues (tracker, network-manager-applet, libpeas)
Le vendredi 25 février 2011, à 18:08 -0600, Dan Williams a écrit : On Thu, 2011-02-24 at 21:32 +0100, Frederic Peters wrote: Dan Williams wrote: This looks like you're using a tarball for the build instead of upstream jhbuild's module that pulls from git master? I can't seem to find This is because we release GNOME versions as a set of tarballs; and we produce individual modulesets targetting those, see this one for an example: http://ftp.gnome.org/pub/GNOME/teams/releng/2.91.90/gnome-suites-core-2.91.90.modules This is also why the release team publishes a schedule, sends tarballs due emails, nag people for tarballs, etc. And that's why if you want to be be a core GNOME module, you should follow the schedule, publish tarballs in due time, etc. Well, it's not really a core gnome module and will eventually be supplanted by the shell's built-in indicator applet. Yes, we do need a tarball release off git master. But clearly including code from branches that are not meant to be used with latest GNOME isn't going to work... Which is why tarballs from the right branch are useful :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libpanel-applet-3 and gtk 2
Le mercredi 09 février 2011, à 22:59 +0200, Aurimas Černius a écrit : Hi, Will there be a gtk2 version of libpanel-applet-3 when GNOME 3.0 is released? There is libpanel-applet-4 for the fallback mode in GNOME 3. There's no plan to have a gtk2 version of it, at the moment. It's certainly doable, though, but I don't see much point in doing so. I'd guess it's just a matter of taking libpanel-applet-3 and updating it for the dbus protocol changes (mostly in background handling); and removing the option to run the applets in-process. [...] The same question is for Bonobo applets. Will they still be supported? Not excessively hard to do so, but not being actively worked on right now. I'm not sure it's worth investing time in there, since the number of applets that were developped over years is rather small... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump telepathy-glib minimum version
Le jeudi 27 janvier 2011, à 23:47 +, Emilio Pozuelo Monfort a écrit : Hi, I'd like to bump the minimum telepathy-glib requirement to 0.13.11, which we need for Empathy. It's currently at 0.13.9, and 0.13.x is the unstable series leading to the stable 0.14 release, which we'll want for GNOME 3.0 anyway. In general, feel free to update until 0.14.0 :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.91.5 status
Hi, Earlier today, I uploaded 2.91.5 modulesets at http://download.gnome.org/teams/releng/2.91.5/ I've run a first build, and nearly everything builds. The exceptions: + gobject-introspection 0.10.0. Some issue with the latest glib. It's fine in git, and Colin is planning a release. + gtkmm 2.91.7. It fails with ../gdkmm/display.h:436:3: error: ‘GdkDisplayPointerHooks’ does not name a type It might be fixed in git, didn't check. + vte 0.27.3. Still uses gtk_quit_add(), fixed in git. So a new tarball would be great. + gnome-terminal 2.33.3.1. It looks for gtk-builder-convert-3.0, fixed in git. Again, a new tarball would be nice. I haven't tested anything at runtime, though, so maybe it's a complete disaster ;-) We'll see tomorrow. I just know of a crasher in glib for gnome-panel, but Matthias was talking about doing a new glib release with the fix. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 2.91.4 status (was Re: GNOME 2.91.4 build issues)
Hi all, Woohoo, I'm not sure we've ever been that late for a release ;-) Bad idea to do a release at the end of the year, it seems :-) So all of the blockers for 2.91.4 are now fixed in git, and we even got a new gtk-theme-engine-clearlooks with fixes. The only thing blocking the release is that the GTK+ fixes are only in git, so we'd need a new GTK+ 2.91 tarball. Is this something that will happen? FWIW, I'm not going to release a GNOME version with a GTK+ that I consider too broken; if we're not going to have a new GTK+ 2.91 tarball in the next few days, maybe we should just skip 2.91.4 since 2.91.5 will be released on January 12th. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Le mercredi 29 décembre 2010, à 09:34 +0100, Josselin Mouette a écrit : Le mardi 28 décembre 2010 à 16:53 +0100, Carlos Garcia Campos a écrit : Is the GNOME 3 panel compatible with the GNOME 2 applets? There's no gnome 3 panel, gnome-panel hasn't been ported to gtk3 yet, there's a branch but it's outdated and it still doesn't work. That’s good then. But does this panel work fine with the GNOME 3 components? Especially the new control-center ? That work hasn't been done yet, but it shouldn't be a big deal to make it work with the new control center. To answer other gnome-panel GNOME 3 questions in this thread: + I want to have gnome-panel use gtk+ 3, yes. Patches welcome, since every time I try to secure time for this, I fail. + even if we move to gtk+ 3, there's no hard difficulty in maintaining bonobo compatibility for applets, as an external module to gnome-panel. We can simply take the compatibility module that exists today and move it out of process. I certainly do hope that this thread indicates that some people want to step up to do some active maintenance of gnome-panel ;-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le vendredi 24 décembre 2010, à 01:33 +0100, Vincent Untz a écrit : Le jeudi 23 décembre 2010, à 20:01 +0100, Vincent Untz a écrit : + latest empathy doesn't build with latest gnome-keyring: gcr-simple-certificate.c:122:1: error: conflicting types for ‘gcr_simple_certificate_new’ /gnome/releases/usr/include/gcr-3/gcr/gcr-simple-certificate.h:57:21: note: previous declaration of ‘gcr_simple_certificate_new’ was here Apparently, some code was pasted from gnome-keyring and since they share the same prefix... Not fixed. Potential blocker. Guillaume fixed this, and will release a new tarball. Thanks! + interestingly, when there's no icon theme set by g-s-d, metacity goes crazy with: metacity:ERROR:ui/ui.c:752:meta_ui_get_default_window_icon: assertion failed: (default_icon) Not fixed, but not a blocker. Will file a bug tomorrow. https://bugzilla.gnome.org/show_bug.cgi?id=637933 + GNOME Shell doesn't start if you don't have introspection from gnome-bluetooth. I guess it could survive this. But no big deal. https://bugzilla.gnome.org/show_bug.cgi?id=637935 + gnome-settings-daemon crashes if the media-keys plugin is enabled (which is the case by default). Disabling it in gsettings works. https://bugzilla.gnome.org/show_bug.cgi?id=637936 + after login, the wallpaper is drawn after a few seconds, and then becomes black. It's fine again if I start nautilus. I'm not sure what is to blame here (g-s or g-s-d?) Lateness might be https://bugzilla.gnome.org/show_bug.cgi?id=568385 Black bacground is https://bugzilla.gnome.org/show_bug.cgi?id=637938 + probably a theming issue: tabs are not drawn where they should be. They're drawn something like 50px or 100px below. https://bugzilla.gnome.org/show_bug.cgi?id=637940 + GtkSpinButtons don't have the down arrow, and make the app crash if I try to use the up arrow. I quickly looked at the stack trace, and it looked like it was possibly related to the theming engine. Missing arrow: https://bugzilla.gnome.org/show_bug.cgi?id=637942 Crash: https://bugzilla.gnome.org/show_bug.cgi?id=637943 (filed against GTK+ since there's no product for gtk-theme-engine-clearlooks) + there's a general issue with starting launchers: most (all?) don't work in gnome-shell, and if I go to $prefix/share/applications in nautilus, I can't launch them either. I've no idea why this is happening, though, and it could well be a local issue. Not filed yet, need to investigate what's going on. + dconf-editor crashes when I go in /desktop/gnome/interface https://bugzilla.gnome.org/show_bug.cgi?id=637944 I also filed: + lock settings don't get saved https://bugzilla.gnome.org/show_bug.cgi?id=637939 + system information panel is hardcoded https://bugzilla.gnome.org/show_bug.cgi?id=637941 And I might file more later... FWIW, at the moment, I consider the theming issues, the g-s-d issue and the crash in GtkSpinButton as blockers. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le vendredi 24 décembre 2010, à 12:31 +0100, Vincent Untz a écrit : Le vendredi 24 décembre 2010, à 01:33 +0100, Vincent Untz a écrit : + there's a general issue with starting launchers: most (all?) don't work in gnome-shell, and if I go to $prefix/share/applications in nautilus, I can't launch them either. I've no idea why this is happening, though, and it could well be a local issue. Not filed yet, need to investigate what's going on. Looks like a GDK crash in 2.91.7: https://bugzilla.gnome.org/show_bug.cgi?id=637949 That's a blocker too. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le mercredi 22 décembre 2010, à 21:21 +0100, Philippe Rouquier a écrit : Hi, Le mercredi 22 décembre 2010 à 16:24 +0100, Vincent Untz a écrit : brasero === Need fixes from git + updated eggsmclient That is fixed after the latest changes (thanks to Mathias for updating libegg). Would it be possible to get a tarball with those changes? :-) I can do it if you don't have time. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
System Information vs gnome-about
Hi, I see that gnome-about got removed from gnome-desktop, with the message that it should be replaced with the system information panel (see http://live.gnome.org/Design/SystemSettings/SystemInformation) Is this system information panel available somewhere? Is someone working on it? If no, I think it's weird to remove gnome-about before we get a replacement... Especially as we could easily tweak gnome-about to implement the proposed design. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System Information vs gnome-about
Le jeudi 23 décembre 2010, à 11:06 +0100, Vincent Untz a écrit : Hi, I see that gnome-about got removed from gnome-desktop, with the message that it should be replaced with the system information panel (see http://live.gnome.org/Design/SystemSettings/SystemInformation) Is this system information panel available somewhere? Is someone working on it? If no, I think it's weird to remove gnome-about before we get a replacement... Especially as we could easily tweak gnome-about to implement the proposed design. Okay, I see it's in gnome-control-center now (just appeared in the last release), but with static data. We also lost gnome-version.xml, which I think was used by other modules (at least bug-buddy and gnome-system-monitor). I think we still need to have one file telling the exact version of GNOME. Is this something we should ship in g-c-c too? Or I can add it back to gnome-desktop, since we're used to doing tarballs of this one just to bump the GNOME version anyway. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le mercredi 22 décembre 2010, à 16:24 +0100, Vincent Untz a écrit : Hi, I've been trying to build GNMOE 2.91.4 from tarballs, and it's not looking good at all :-) Thanks to everybody who helped. We've made good progress, but we're still not there: + I need to test latest gnome-packagekit evince tarball, but they should build fine now. + latest empathy doesn't build with latest gnome-keyring: gcr-simple-certificate.c:122:1: error: conflicting types for ‘gcr_simple_certificate_new’ /gnome/releases/usr/include/gcr-3/gcr/gcr-simple-certificate.h:57:21: note: previous declaration of ‘gcr_simple_certificate_new’ was here Apparently, some code was pasted from gnome-keyring and since they share the same prefix... + yelp doesn't build with gtk+ 2.91.7, but Shaun is on it. + latest gnome-settings-daemon is using some API removed in GTK+ 2.91.7, but nobody noticed until we tried using it. Cosimo is on it. + we need a new GTK+ 2.23 release (or we'll use an old one). The current one needs a fix from git. Without it, gnome-panel doesn't even start. + interestingly, when there's no icon theme set by g-s-d, metacity goes crazy with: metacity:ERROR:ui/ui.c:752:meta_ui_get_default_window_icon: assertion failed: (default_icon) That was just from a small test in xephyr. Hopefully, the gnome-shell side of things works better :-) Will take a look at it later. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Hey, Quick update: Le jeudi 23 décembre 2010, à 20:01 +0100, Vincent Untz a écrit : + I need to test latest gnome-packagekit evince tarball, but they should build fine now. Works fine. + latest empathy doesn't build with latest gnome-keyring: gcr-simple-certificate.c:122:1: error: conflicting types for ‘gcr_simple_certificate_new’ /gnome/releases/usr/include/gcr-3/gcr/gcr-simple-certificate.h:57:21: note: previous declaration of ‘gcr_simple_certificate_new’ was here Apparently, some code was pasted from gnome-keyring and since they share the same prefix... Not fixed. Potential blocker. + yelp doesn't build with gtk+ 2.91.7, but Shaun is on it. Fixed. + latest gnome-settings-daemon is using some API removed in GTK+ 2.91.7, but nobody noticed until we tried using it. Cosimo is on it. Got fixed, but see below. + we need a new GTK+ 2.23 release (or we'll use an old one). The current one needs a fix from git. Without it, gnome-panel doesn't even start. We'll use an old GTK+ 2.23. + interestingly, when there's no icon theme set by g-s-d, metacity goes crazy with: metacity:ERROR:ui/ui.c:752:meta_ui_get_default_window_icon: assertion failed: (default_icon) Not fixed, but not a blocker. Will file a bug tomorrow. That was just from a small test in xephyr. Hopefully, the gnome-shell side of things works better :-) Will take a look at it later. GNOME Shell works fine, but I found various issues, and it's not acceptable to release something with the current state. Some of those issues might be local to my computer, but probably not all. It's too late here to file bugs, but I'll do that tomorrow. + GNOME Shell doesn't start if you don't have introspection from gnome-bluetooth. I guess it could survive this. But no big deal. + gnome-settings-daemon crashes if the media-keys plugin is enabled (which is the case by default). Disabling it in gsettings works. + after login, the wallpaper is drawn after a few seconds, and then becomes black. It's fine again if I start nautilus. I'm not sure what is to blame here (g-s or g-s-d?) + probably a theming issue: tabs are not drawn where they should be. They're drawn something like 50px or 100px below. + GtkSpinButtons don't have the down arrow, and make the app crash if I try to use the up arrow. I quickly looked at the stack trace, and it looked like it was possibly related to the theming engine. + there's a general issue with starting launchers: most (all?) don't work in gnome-shell, and if I go to $prefix/share/applications in nautilus, I can't launch them either. I've no idea why this is happening, though, and it could well be a local issue. + dconf-editor crashes when I go in /desktop/gnome/interface Those are the visible issues I met after playing a bit. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 2.91.4 build issues
Hi, I've been trying to build GNMOE 2.91.4 from tarballs, and it's not looking good at all :-) Matthias already mentioned some breakages caused by GTK+ 2.91.7, but it's not just that. Here are the tarballs that I have and that don't build: brasero 2.91.3 evolution-data-server 2.91.4 empathy 2.91.4 eog 2.91.4 evince 2.91.3 gnome-control-center 2.91.3.1 gnome-packagekit 2.91.3 gnome-power-manager 2.91.3 gnome-screensaver 2.91.1 gnome-session 2.91.0 gnome-shell 2.91.3 gnome-terminal 2.33.3 gnome-user-share 2.30.1 gnome-utils 2.91.1 gnome-settings-daemon 2.91.5.1 gucharmap 2.33.1 libgnomekbd 2.91.3.1 mutter 2.91.3 nautilus 2.91.5 notification-daemon 0.5.0 totem 2.91.0 vino 2.32.0 vte 0.27.2 zenity 2.91.1 You'll find more details for each module below. When releasing a new tarball, please make sure to build against GTK+ 2.91.7 :-) brasero === Need fixes from git + updated eggsmclient evolution-data-server = e-source-selector-dialog.c:105:2: error: implicit declaration of function ‘gtk_widget_ensure_style’ e-source-selector-dialog.c:105:2: warning: nested extern declaration of ‘gtk_widget_ensure_style’ empathy === Fails to build with GTK+ 2.91.7: gdk_spawn_on_screen, gdk_xid_table_lookup eog === Fails to build with GTK+ 2.91.7: gdk_spawn_command_line_on_screen evince == Needs at least the updated eggsmclient. gnome-control-center Fails to build with GTK+ 2.91.7: gdk_spawn_command_line_on_screen gnome-packagekit Fails to build with GTK+ 2.91.7: gdk_window_foreign_new_for_display gnome-power-manager === configure fails: No package 'gdk-x11-3.0' found (got removed from GTK+ 2.91.7, but Matthias mentioned it might come back) gnome-screensaver = Fails to build with GTK+ 2.91.7: gdk_spawn_on_screen_with_pipes, gdk_window_lookup, gdkx_visual_get gnome-session = Needs at least the updated eggsmclient. gnome-shell === configure fails: No package 'gdk-x11-3.0' found (got removed from GTK+ 2.91.7, but Matthias mentioned it might come back) gnome-terminal == Requested 'vte-2.90 = 0.27.3' but version of vte is 0.27.2 (there's no vte 0.27.3 yet) gnome-user-share Need a new release (git builds fine) gnome-utils === Needs at least the updated eggsmclient. gnome-settings-daemon = Need a new release (git builds fine) gucharmap = Need a new release (git builds fine) libgnomekbd === configure fails: No package 'gdk-x11-3.0' found (got removed from GTK+ 2.91.7, but Matthias mentioned it might come back) Some other fixes are in git. mutter == Fails to build with GTK+ 2.91.7: gdk_window_lookup_for_display, gdk_xid_table_lookup, gdk_text_property_to_utf8_list Some other fixes are in git. nautilus Fails to build with GTK+ 2.91.7: gdk_spawn_command_line_on_screen notification-daemon === Need a new release (git builds fine) totem = Need a new release (git builds fine) vino Need a new release (git builds fine) vte === Need a new release (git builds fine) zenity == Fails to build with GTK+ 2.91.7: gdk_window_foreign_new -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le mercredi 22 décembre 2010, à 16:24 +0100, Vincent Untz a écrit : Here are the tarballs that I have and that don't build: I forgot clutter-gtk (might be fixed in git). Also, libchamplain builds against GTK+2. Since our main use is in empathy right now, it means we can't use it all. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.4 build issues
Le mercredi 22 décembre 2010, à 21:02 +0100, Xan Lopez a écrit : WebKitGTK+ and ephy are not in the list (I guess you gave up on them!), but they don't actually work with GTK+ 2.91.7 either (they worked with what was on master the day I released). I'll try to make new releases ASAP of both. Thanks; I had WebKitGTK+ somewhere else on my list, actually :-) It also means I've no idea whether apps depending on it build with GTK+ 2.91.7 (yelp, devhelp, etc.). So something to check later on, I guess. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: x-jhbuild-0.2 can be used with gnome, too
Hi, Le jeudi 18 novembre 2010, à 11:28 +0100, Dirk Wallenstein a écrit : Hi, I just released x-jhbuild-0.2 and as it can be used with gnome, too, I thought I post a note. What's the difference between x-jhbuild and jhbuild? :-) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.1 status
Le mercredi 20 octobre 2010, à 22:29 +0300, Zeeshan Ali a écrit : Hi, gupnp-av doesn't build with error on introspection. http://bugzilla.openedhand.com/show_bug.cgi?id=2202 Vincent pointed this issue out two weeks ago and it has been fixed in git master ever since. I asked if a release with fix is needed but I was told that that its not (at least by Vincent) so I didn't release. Now I'm sick so I asked Ross to roll it out. Just to clarify: the fix was not needed for 2.32, but 2.91 is another story. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
Le vendredi 15 octobre 2010, à 17:02 +0200, daniel g. siegel a écrit : On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. We should improve our infrastructure if possible, sure. But it's a fact that there will be GNOMEy stuff not hosted on gnome.org, whatever we do. So we'll have to find a solution for this anyway. Let's not think that the whole world is wrong, and that we should host everything. Let's be pragmatic and accept that people might have different opinions on what is the best infrastructure :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel - gtk3
Le jeudi 14 octobre 2010, à 15:38 +0200, Jan de Groot a écrit : On Wed, 2010-10-13 at 17:50 -0300, Jonh Wendell wrote: Hi, folks. Will we have a gnome-panel ported to gtk3? We need it for gnome 3 as fallback for gnome-shell, right? It will eventually, yes. Help welcome, etc. Note that Benjamin had some patches in bugzilla that should help a bit. Porting gnome-panel will be pain I think, at least when we're talking about the bonobo applet loader plugin that is available for backwards compatibility now. If gnome-panel is ported to gtk3, either that module gets dropped, or it is changed to an out-of-process binary, as it depends on libbonobo, which will never ever get ported to gtk3. We can still do something about that. We just need to make the bonobo compatibility module out-of-process. So I don't think it would be such a big deal. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le lundi 11 octobre 2010, à 23:20 +0200, Kenneth Nielsen a écrit : I would like to elaborate on one very important thing that you mention, and that is that if a project chooses not to follow the GNOME release schedule, the key is information. So when/(if) this happens it has to be extremely visibly, preferably right there in l10n.org. So I would suggest as a technical detail to your proposal, that it is a _requirement_ for project maintainers of projects that don't follow the GNOME release schedule, to not only document it in their development fora, but also to publish a (tentative) string freeze and release date somewhere in the repository, so that it can be automatically parsed and published on damned lies. Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010, à 17:08 +0200, Piñeiro a écrit : From: Johannes Schmid j...@jsschmid.de Hi! Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x Desktop moduleset. However, we would like to slowly migrate some modules to the Applications moduleset. I guess everything related to accessibility will stay in Desktop, right? This is a good question, and I have some doubts, probably because in some cases there are a thin line between Core Desktop and Applications I guess that in this proposal modules like at-spi2-atk or pyatspi2 will be obviously in the Core Desktop, as they are fundamental to the a11y support. Right. But if we move forward toward the line we find Orca: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? I don't know a lot about accessibility, but to me, orca is (or at least, was so far -- maybe it will change with a11y integration in the shell?) a core part of the desktop for accessibility. It's what most people use to really make the desktop accessible in the way they need. And if we keep moving forward we find Accerciser: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? * Well, yes, basic module, but for developers = additional point to move it to Applications? Accerciser, on the other hand, is a tool that is not useful for most people. It's really a tool for developers (so there's no reason for it to be in the Core), so it'd go in Applications. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le samedi 09 octobre 2010, à 09:25 +0200, Josselin Mouette a écrit : Le jeudi 07 octobre 2010 à 13:38 +0200, Vincent Untz a écrit : API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. I’m thrilled to finally see guaranteed ABI stability on D-Bus interfaces. This has been one of the major problems we had to deal with upon upgrades. Unlike shared libraries, t is ver It's worth pointing out that, so far, we have no dbus interface that provides stability guarantees :-) Hopefully, saying that we can have that in the platform will help maintainers decide to od it. The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). Where do you draw the line with some applications that should be part of any desktop, like eog and evince? Right. That's the hard question :-) And that's an issue we have today: how do we define the desktop? Should it include a browser (we chose yes a few years ago), a video player (again, we chose yes), a IM client (we only chose yes recently), a music library (so far, we stayed with no, but nearly all users use one). I know Jon has been thinking about this and proposed a list of core utilities that included some tools. We do need help to take a decision here. + we strongly encourage the application developers to follow the GNOME development cycle. If a different development cycle is used, it has to be documented to help contributors. Without that, how do you decide, at the time of the release, which version of the application will go into the release? If a different development cycle is used, it has to be documented (as mentioned). So we can know what will be the stable version at the time of the GNOME release, and therefore which version can be used. Or am I missing something? This is not an innocent question; when something changes (often in an incompatible way) in the extended platform, you need to ensure that all applications work consistently with it. Nod. Which is why most people will just use the GNOME cycle anyway ;-) I mean this issue already exists as of today with applications that are not blessed by GNOME, and it works fine in the end, doesn't it? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010, à 16:50 +0200, Murray Cumming a écrit : On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: + feedback will not be centered around the goal of the application, but about its technical merits: - use of GNOME technologies - integration with the Core Desktop - usability and respect of the HIG - existence of localization issues or not - status of documentation - accessibility support But you will still require these modules to actually follow the release schedule, right, such as feature freezes, string freezes, UI freezes, hard-code freeze, etc? This was mentioned later in the proposal: we encourage app developers to follow the GNOME schedule. But if they don't, they need to publish their schedule. We think most people will adopt the GNOME schedule, but some app developers might have different needs. For example, I talked to the Shotwell developers at GUADEC, and they currently use cycles that are much shorter than six months. What matters is that there is a documented schedule, and that there are proper freezes. It doesn't have to be the GNOME schedule, although it's nicer for us. The point of the release sets (and the release team) is still to release software, I hope. Sure. And the way it works wouldn't change for the platform and the core desktop. But for applications, the way we work would need to be adjusted a bit. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. (That's also what transifex wants to do in the future) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Moduleset Reorganization -- Take two
Hi, The release team updated the proposal to reorganize the modulesets. We discussed a first version back in June [1], and there are a few visible changes: - we added a system platform category in the platform, and we now also talk about dbus services there. - we listened to the feedback where people didn't like the fact that inclusion of applications had no barrier to entry at all. We do think the Core Desktop vs Applications separation is good, and we also believe it's important to simplify the process and to be more liberal for simple applications (ie, applications that won't be in the Core Desktop). - we also listened to translators, who have a need for a simple workflow. There is no perfect solution for now, but we propose a way forward. This is obviously an important topic, so please take some time to read the proposal and send feedback. I apologize for this being a bit late; purely my fault. Cheers, Vincent [1] http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg1.html == GNOME Moduleset Reorganization: Platform, Bindings == We identified various issues with our current Platform moduleset: + bindings are not part of it, and feel like second-class citizen. + some libraries that are targetted at the platform are not API/ABI stable yet. While we should still encourage their use instead of their alternatives, we didn't have a clear message for this yet. + many modules that are actually part of our platform just appear as external dependencies. + dbus services were not technically part of our platform, while they do provide API/ABI to developers too. System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. However, to the libraries of the GNOME 2.x moduleset, we also add the stable bindings for GNOME, to make them first-class citizen in our message to developers. Extended Platform = The Extended Platform is a set of libraries or dbus services that do not provide API/ABI stability yet, but that fill holes in our platform and that should end in our platform once they reach stability. We encourage developers to use them instead of alternative solutions. Additionally, bindings that are still in development will also be in the Extended Platform. Candidates for this set include GStreamer, enchant, evolution-data-server, libcanberra, libgda, libnotify, gupnp, poppler, telepathy-glib, tracker, webkitgtk. Candidate bindings include java-gnome. = GNOME Moduleset Reorganization: Desktop, Admin, Dev Tools = The original idea to have Desktop, Admin and Dev Tools modulesets was to separate some applications based on the target user: end-user, system administrator, or developer. It worked okayish, but it turned out that most applications just ended up in Desktop, and it started getting harder and harder to put a limit on what kind of application can live in the Desktop. Moreover, when there are competing applications for a same use case, we could not choose one application without sending a message that the other applications were not as good, and this forced us to stay neutral (the classical banshee vs rhythmbox example). We propose a solution where we keep a core desktop, which is the part of GNOME that everybody uses, and applications, containing the various applications that people use. Note: related to this, it's worth considering a tag-based approach instead of single-category like we did. The categories defined in the xdg menu specification can be used for this, whenever we will have to present applications in a categorized way. Core Desktop The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). This Core Desktop will be a moduleset, in the same way we did the Desktop moduleset for GNOME 2. It will have the same rules, including the requirement to use GNOME resources. Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x
Re: New module proposal: Clutter core
Le mardi 05 octobre 2010, à 18:41 +0200, Johannes Schmid a écrit : Hi! I'm pretty sure the GNOME infrastructure could do the same thing: get the POT file from git.clutter-project.org (it's generated by gettext and stored in the repository anyway); send me an email with the PO file once the coordinator has reviewed the contribution. I could even allow commit access to a branch, or a user repository that I can pull from. That would work (in might be a good idea to implement for git repositories in general). We didn't manage to commit to GNOME git yet though and I doubt it would be easier on other repositories. It's something that could be considered in long-term, also for some freedesktop modules. alternatively, GNOME could have a private Clutter core repository for i18n purposes alone - after all, we're using Git. We do that for some other modules and it works OK. Note: As stated before I am not so much concerned about clutter itself but about our general policy on handling external repositories. For git it might kind of work but for other things like launchpad it could become worse. I think the right solution is to improve l10n.gnome.org so that it can interacts with other platforms (like transifex) where there is a team control. Alternatively we can also investigate something similar to where transifex is heading to: host the po files on l10n.gnome.org and add some autofoo magic that would download the po files from there during 'make dist'. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump telepathy-glib requirement
Le mardi 28 septembre 2010, à 16:55 +0200, Guillaume Desmottes a écrit : Hi, Empathy 2.91.x/3.0 will depend on telepathy-glib 0.13.x. We just released telepathy-glib 0.13.0 [1] which starts the new cycle. Plans for this cycle include the very popular high level API on Telepathy channels which should allow us to drop a lot of code from Empathy and make Telepathy much easier to use in any application. As we did with 0.12 we'll release telepathy-glib 0.14 in time for GNOME 3.0 so distributions would be able to ship the stable branch. If no objection, I'll update the wiki and jhbuild to reflect this. Go ahead. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.32.0 status (was Re: Additional 2.32.0 tarballs :-))
Hi, We're quite close to 2.32.0. Thanks to everyone who helped today! There are still a few issues: + some modules need a new release to get a working introspection build: - clutter-gtk, and it's already fixed in git: http://git.clutter-project.org/clutter-gtk/commit/?h=clutter-gtk-0.10id=4de105a2bbd201c8e60f3e894a4cd532afdc - gupnp-av: I mailed Zeeshan - libgdata: simple patch available at https://bugzilla.gnome.org/show_bug.cgi?id=630756 - pango: patch avalable at https://bugzilla.gnome.org/show_bug.cgi?id=630857 + I'm still waiting for a new metacity tarball, that would revert the drawing to go back to gdk, to fix https://bugzilla.gnome.org/show_bug.cgi?id=630426 I will still accept tarballs for a few modules, but I will not block the releases for them. It's hard for me to know if the changes in git should be released or not, so maintainers, please have a look: - gnome-icon-theme - gnome-icon-theme-symbolic - seahorse-plugins - maybe glade3: I guess it's up to Tristan to see if what's in gnome-2-28 can be released as glade 3.6.8 - maybe gtk-engines: need information from maintainers I've published jhbuild modulesets for people who want to give it a try: http://download.gnome.org/teams/releng/2.32.0/ It builds fine (except for the introspection issues in four modules, highlighted above), and after playing briefly with it, I didn't see any other blocker bug. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91/3.0 Schedule Draft
Le lundi 27 septembre 2010, à 08:54 +0200, Johannes Schmid a écrit : Hi! A first draft for the GNOME 2.91/3.0 schedule is now available at http://live.gnome.org/TwoPointNinetyone . What happened to the discussion about a some kind of new module structure that we discussed some time ago. I think it would be good to have that settled before module inclusion heats up. New draft coming soon :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Additional 2.32.0 tarballs :-)
Hey all, The deadline for 2.32.0 tarballs has passed :-) I've taken a look at modules that didn't get a tarball, and found that we could do with some more tarballs. See the list below. I'll likely go ahead and release tarballs tomorrow (at least for the modules where there is no real code change since last release). Help is of course welcome -- as long as it doesn't distract you too much from the real work: GNOME 3. Just two things if you're going to release something without being the maintainer: make sure to release from the right branch, and do not bump the version number uselessly (ie: instead of jumping to 2.32.0, it's fine to release 2.28.5 if the previous release was 2.28.4, if the module wasn't branched, and if there is no major change in git). If you have any doubt, you can ping me on IRC. Cheers, Vincent Modules that need some work before a release: - gnome-python-desktop: doesn't build with evince, and 2.31.x version - metacity: theme issue (move to cairo should get reverted on branch) Modules where it's unclear if we want a new release: - gobject-introspection: do we need a new release? - gtk-engines: some changes, but no 2.21 release so far - all the C# bindings: no idea what's going on there. Modules with changes in git, that could do with a release: - accerciser: translations - evolution-webcal: translations, and 2.31.x version - gdl: some translations (gnome-2-30) - gedit: some translations in 2.30 branch - glade3: some fixes, translations (gnome-2-28) - gnome-bluetooth: translations, and 2.31.x version - gnome-devel-docs: translations - gnome-doc-utils: translations - gnome-icon-theme: some changes - gnome-icon-theme-symbolic: some changes - gnome-mag: a few fixes, translations - gnome-media: translations, build fixes, and 2.31.x version - gnome-netstatus: translations, build fix - gnome-nettool: translations, and 2.31.x version - gnome-screensaver: some fixes in gnome-2-30, we probably don't want master since there was no release from there - gnome-system-monitor: build fixes, translations - gnome-themes: 2.31.x version, just need a version bump - gnome-user-docs: some changes, translations - gnome-vfs: mostly translations - gok: translations - gtksourceview: translations - libbonoboui: some translations - libgnomeprint: translations - libgnomeprintui: translations - libgtop: translations - libsoup: 2.31.x version, just need a version bump - nautilus-sendto: translations, 2.31.x version - ORBit2: one fix in master - sabayon: translations - seahorse-plugins: small fixes, translations - sound-juicer: translations, 2.31.x version - swfdec-gnome: translations, one fix - totem-pl-parser: translation, 2.31.x version - vinagre: translations - yelp: one fix, translations (gnome-2-30) - zenity: translations, 2.31.x version Modules with changes, but where we'll keep the old version: - ekiga: many changes, but not release in a long time, so prefer to stay with 3.2.7. - pango: some fixes in master, but we didn't get any 1.29 release, so we stay with 1.28. Nothing interesting in 1.28 branch. Modules with releases done according to git, but not on FTP yet: - gnome-user-share: 2.30.1 not uploaded yet? - seahorse: 2.32.0 not uploaded yet? -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
Le mercredi 15 septembre 2010, à 12:47 +0200, Vincent Untz a écrit : Hi, I'm working on 2.31.92, and it's fun. Or actually, it's not :-) Help from various maintainers is needed to make this release happen. So, we finally got the new glib. I'm back with new issues, though... totem: still uses GApplication. The release team will go ahead and change the gnome-2-32 branch to use libunique. folks: need a new release, because it doesn't build with latest vala (which is needed for latest g-i). The fix in git that we want is http://git.gnome.org/browse/folks/commit/?id=858fc13f485d5d5b8b0721f6c8096c671e46aca0 I'll release it myself in the next 3 or 4 hours if I have no news from the maintainers :-) webkitgtk: will fail because WebKit/gtk/JSCore-1.0.gir is using the 1.1 gir format, instead of the new 1.2 format. Webkit people, we need a tarball! I'm pretty sure I'll find more issues later on... I do hope that people realize it's extremly bad to have so many build issues for a .92 release. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
Le jeudi 16 septembre 2010, à 09:40 +1000, Danielle Madeley a écrit : On Wed, 2010-09-15 at 12:47 +0200, Vincent Untz wrote: - telepathy-glib: Namespace conflict for 'iface_quark_connection_manager'. I think that's something that should get fixed in g-i? What tp-glib are you building? This should be fixed since 0.11.15. Yes, that's fine now. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
Le mercredi 15 septembre 2010, à 12:47 +0200, Vincent Untz a écrit : I'm working on 2.31.92, and it's fun. Or actually, it's not :-) Help from various maintainers is needed to make this release happen. Most of the issues are now fixed (still waiting for a few tarballs, but I'm sure they'll come soon). So now, the release is blocking on the next glib release :-) I've been told we'd get a new glib before the week-end, and since it will change some API introduced this cycle, I want to make sure that 2.31.92 builds fine with it. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Maintainers, please read: 2.31.92 fun
Hi, I'm working on 2.31.92, and it's fun. Or actually, it's not :-) Help from various maintainers is needed to make this release happen. First, let me introduce a new rule: Rule: the release team will feel free to commit to any module where *_DISABLE_DEPRECATED or -Werror flags are enabled by default in tarballs. It's fine to have those flags by default when building from git, but not from tarballs. We've told that several times in the past, and the release team is hit by this issue for every release, so I guess it's time to just fix it. This week, with the deprecation of GDK_DISPLAY()/gdk_display in GTK+ 2.21.8, we have a bunch of modules that fail to build: - clutter-gtk (okay, we can't commit there ;-)) - epiphany - gnome-disk-utility (fixed in git) - metacity (use -Werror) - tomboy - totem (There were a few others, but they got fixed already,thanks to the maintainers) Next is gobject-introspection: Colin has been working hard to fix various issues (still waiting for a new gobject-introspection tarball with those fixes, though). Unfortunately, it turns out that this breaks some builds: - gstreamer: we need the gstreamer fix from https://bugzilla.gnome.org/show_bug.cgi?id=550616. However, there's no gstreamer release planned before October... - totem-pl-parser: https://bugzilla.gnome.org/show_bug.cgi?id=629342 - libgee: the gir file generated by vala has a 1.1 format, instead of the new 1.2 format. So I guess we need a new vala, with this patch: https://bugzilla.gnome.org/show_bug.cgi?id=628927 - telepathy-glib: Namespace conflict for 'iface_quark_connection_manager'. I think that's something that should get fixed in g-i? - polkit: Namespace conflict for 'implicit_authorization_get_type'. Same as above. - gnome-games: https://bugzilla.gnome.org/show_bug.cgi?id=629619 That's the issues I had so far. I'm still waiting for a glib tarball (Ryan?), which will remove GApplication, IIRC. I hope everything is ready for this... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
Le mercredi 15 septembre 2010, à 12:47 +0200, Vincent Untz a écrit : Next is gobject-introspection: Colin has been working hard to fix various issues (still waiting for a new gobject-introspection tarball with those fixes, though). Unfortunately, it turns out that this breaks some builds: I forgot dconf here. It just needs a tarball since the fix is in git. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
Le mercredi 15 septembre 2010, à 11:09 -0400, Colin Walters a écrit : On Wed, Sep 15, 2010 at 6:47 AM, Vincent Untz vu...@gnome.org wrote: - gstreamer: we need the gstreamer fix from https://bugzilla.gnome.org/show_bug.cgi?id=550616. However, there's no gstreamer release planned before October... I can work around it probably. That's be great! - totem-pl-parser: https://bugzilla.gnome.org/show_bug.cgi?id=629342 This is fixed. - libgee: the gir file generated by vala has a 1.1 format, instead of the new 1.2 format. So I guess we need a new vala, with this patch: https://bugzilla.gnome.org/show_bug.cgi?id=628927 The vala integration is the highest risk right now. However in the case of libgee/dconf, I believe we can just drop the .gir file with no harm as nothing depends on them.. Jürg told me he might do a vala release tonight, which would fix this. - telepathy-glib: Namespace conflict for 'iface_quark_connection_manager'. I think that's something that should get fixed in g-i? Are you testing a tarball or git? Tarball; I've been told it's fixed in git and there'll be a new tarball tonight. - polkit: Namespace conflict for 'implicit_authorization_get_type'. Same as above. This has been fixed in git: - gnome-games: https://bugzilla.gnome.org/show_bug.cgi?id=629619 I'll look into this. I just posted a patch in https://bugzilla.gnome.org/show_bug.cgi?id=629619 Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing old icons from gnome-desktop
Le samedi 07 août 2010, à 16:40 +0200, Vincent Untz a écrit : Hi, For years, gnome-desktop has shipped with old icons that get installed in /usr/share/pixmaps. See http://git.gnome.org/browse/gnome-desktop/tree/pixmaps Unless somebody shouts loud in the next few days, I'll remove those icons from master (ie, gnome-desktop that is targetted at 3.0). They're now gone. RIP. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update of libchamplain version in external dependencies
Le lundi 09 août 2010, à 16:32 +0200, Vincent Untz a écrit : Le lundi 09 août 2010, à 15:54 +0200, Jiří Techet a écrit : Apart from this there are no dependency changes in libchamplain. Thanks for the detailed answer. +1 for the bump. There was no objection, let's do it. Can someone bump the version in the modulesets and on the wiki page? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91 tarballs?
Le lundi 09 août 2010, à 13:54 +0100, Richard Hughes a écrit : For GNOME 2.32 I'm branching my modules from 2.30 and backporting easy stuff from git master. 90% of my development effort is going towards GNOME 3, which is happening on git master. Git master in most of my modules depends on stuff like gtkapplication, gsettings, gdbus and the new control center. Should I release a 2.91.1 tarball soon which contains all the juicy stuff as well as a 2.31.7 tarball which is ready for the release? You can release 2.90.x (not sure why you'd want 2.91 before 2.90 ;-)). Some modules already have such versions. 2.91.1 seems obvious from a this is GNOME 3 beta perspective, but I would rather have some release team approval before I bump up the minor version like that in git master. If the answer is yes, then some other common GNOME modules that provide libraries people need to use might also want to follow suit, for instance gnome-desktop and gnome-control-center. At the moment, it's a bit of mish-mash of versioning for post 2.32 versions. gnome-desktop already have 2.90.x tarballs. g-c-c might need one, indeed. If the g-c-c maintainers can't do it, I can release a tarball for them. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update of libchamplain version in external dependencies
Le lundi 09 août 2010, à 15:25 +0200, Jiří Techet a écrit : I'm a maintainer of the libchamplain library and I would like to ask if its version number in external dependencies could be incremented to the latest release. The version found in gnome-external-deps-2.32.modules of jhbuild is 0.4.5. I would like if the version could be incremented to 0.7.0, which is the latest development version and eventually to 0.8.0 when the stable release is made (which will happen in sync with gnome release schedule). Is there any big change in the dependencies of libchamplain? I've seen that it now depends on memphis -- is this required or optional? Has memphis been packaged by some distro? (this generally helps discover a few issues) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update of libchamplain version in external dependencies
Le lundi 09 août 2010, à 15:54 +0200, Jiří Techet a écrit : Apart from this there are no dependency changes in libchamplain. Thanks for the detailed answer. +1 for the bump. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91 tarballs?
Le lundi 09 août 2010, à 15:39 +0100, Richard Hughes a écrit : On 9 August 2010 14:15, Vincent Untz vu...@gnome.org wrote: You can release 2.90.x (not sure why you'd want 2.91 before 2.90 ;-)). Some modules already have such versions. 90 is an even number, and thus 'stable', surely? Ah, hrm. Don't know, I think some implicit rule we have is that 90 is not stable for us. Or maybe we just declare that 90 is not an even number. At this point, given the fact that we already have various modules with 2.90 releases, you can't make things worse by using 2.90. Nothing else uses 2.91, I think. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
