Re: Proposal: Replace all references to master/slave in GNOME modules
On Wed, May 1, 2019 at 2:09 PM Michael Gratton wrote: > Hi Tristan, > > On Wed, May 1, 2019 at 14:22, Tristan Van Berkom via desktop-devel-list > wrote: > > Instead, by opening the door to censorship of words which are not > > themselves inherently vulgar or foul (i.e. 'master' is not considered > > a > > 'swear word'), we are creating an atmosphere where people worry more > > and more whether they can express themselves freely. > > This has already been covered in the original proposal under objection > (1) "It doesn't matter". As has already been discussed, what actually > doesn't matter is what you or I think, it is the people who have been > affected by the language we use that matter. > *These are the people who won't contribute to GNOME because of these terms*, > and it is the project > that loses out in the end. > Numbers please? For example how many contributors GNOME has lost last year? Do you speak about one or two people? Hundreds people? More? -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
On Thu, Feb 8, 2018 at 8:47 PM, Olav Vitters <o...@vitters.nl> wrote: > I assume Gitlab has some API to show the available repositories. As > such, script is only thing which needs to change. > https://gitlab.gnome.org/Infrastructure/sysadmin-bin/merge_requests/3 Quick test shows that it works, but it must be checked by someone who knows python and/or gitlab api better then me. -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
It is not only script, right? Because repositories.txt does not exist under gitlab.gnome.org. On Thu, Feb 8, 2018 at 12:06 AM, Olav Vitters <o...@vitters.nl> wrote: > On Tue, Feb 06, 2018 at 03:41:03PM +0200, Alberts Muktupāvels wrote: > > > On Tue, Feb 6, 2018 at 3:33 PM, Alberto Ruiz <ar...@gnome.org> wrote: > > > > > > > Hello Alberts, > > > > > > > > I believe the hooks for emails are still installed, so there will be no > > > > regressions in this regard regardless of the web frontend. If the > migrated > > > > projects are not sending commits to the mailing list we're doing > something > > > > wrong. > > > > > > > > > > > > > Migrated projects are sending commits to mailing list, problem is that it > > > is not possible to subscribe to these projects. Migrated projects has > > > disappeared from "Which topic categories would you like to subscribe to?" > > > list - https://mail.gnome.org/mailman/options/commits-list. > > > > The following script needs to be adjusted: > > https://gitlab.gnome.org/Infrastructure/sysadmin-bin/ > blob/master/mail/set-topics-svn-commits-list > > > > > > -- > > Regards, > > Olav > -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
On Tue, Feb 6, 2018 at 3:33 PM, Alberto Ruiz <ar...@gnome.org> wrote: > Hello Alberts, > > I believe the hooks for emails are still installed, so there will be no > regressions in this regard regardless of the web frontend. If the migrated > projects are not sending commits to the mailing list we're doing something > wrong. > Migrated projects are sending commits to mailing list, problem is that it is not possible to subscribe to these projects. Migrated projects has disappeared from "Which topic categories would you like to subscribe to?" list - https://mail.gnome.org/mailman/options/commits-list. Addtionally, now you can use the RSS feature as well as the notification > options per project (the button with the bell icon). > RSS is not same as email, also commit messages are unreadable at least with Firefox: https://gitlab.gnome.org/GNOME/gnome-shell/commits/master?format=atom_token=Jtv8YEwgXqP8TyYtqUx2 Example: > Align and center the date entry with the workspace's > workarea.This way, maximized applications have their window aligned > with the top dateentry.This doesn't change anything for > desktops with no docks or when left/rightworkareas are aligned with > the monitor.The offset is leftOffset - > rightOffset:(workArea.x - monitor.x) - (monitor.width - > ((workArea.x - monitor.x) + workArea.width)) href="https://bugzilla.gnome.org/show_bug.cgi?id=792354; rel="nofollow > noreferrer noopener" target="_blank"> > https://bugzilla.gnome.org/show_bug.cgi?id=792354 > > > 2018-02-06 14:14 GMT+01:00 Alberts Muktupāvels < > alberts.muktupav...@gmail.com>: > >> It is not same, is it? I want to receive emails that are sent to >> commits-list: >> https://mail.gnome.org/archives/commits-list/ >> >> Email is sent also for gitlab projects, but problem is that you can not >> subscribe to these projects. >> >> On Tue, Feb 6, 2018 at 3:04 PM, Carlos Soriano <csori...@gnome.org> >> wrote: >> >>> Hello, >>> >>> This is a built in feature in GitLab. Feel free to subscribe to the RSS >>> for a project in the commits view. For example here in Nautilus >>> <https://gitlab.gnome.org/GNOME/nautilus/commits/master>, click the >>> "wifi"/RSS symbol. >>> >>> Cheers >>> >>> >>> On 6 February 2018 at 13:45, Alberts Muktupāvels < >>> alberts.muktupav...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> question about commits-list: >>>> https://mail.gnome.org/mailman/listinfo/commits-list >>>> >>>> Is there any plan to restore option to subscribe to commits for >>>> projects that has moved to gitlab? >>>> >>>> >>>> On Wed, Jan 24, 2018 at 7:14 PM, Carlos Soriano <csori...@gnome.org> >>>> wrote: >>>> >>>>> Hello all, >>>>> >>>>> Today we hit a milestone, three of the biggest projects in GNOME has >>>>> been migrated, most of our core apps has been migrated, and with this all >>>>> the projects that were part of the deal with GitLab has been migrated. >>>>> >>>>> So allow me to do a short clap . >>>>> >>>>> *Projects migrated today* >>>>> >>>>> - GNOME Shell <https://gitlab.gnome.org/GNOME/gnome-shell> >>>>> - Mutter <https://gitlab.gnome.org/GNOME/mutter> >>>>> - GNOME Software <https://gitlab.gnome.org/GNOME/gnome-software> >>>>> - GNOME Contacts <https://gitlab.gnome.org/GNOME/gnome-contacts> >>>>> - GNOME Tweaks <https://gitlab.gnome.org/GNOME/gnome-tweaks>, >>>>> previously known as gnome-tweak-tool >>>>> - gnome-themes-extra >>>>> <https://gitlab.gnome.org/GNOME/gnome-themes-extra>, previously known >>>>> as gnome-themes-standard >>>>> - GNOME Characters <https://gitlab.gnome.org/GNOME/gnome-characters> >>>>> - D-Feet <https://gitlab.gnome.org/GNOME/d-feet> >>>>> - libwnck <https://gitlab.gnome.org/GNOME/libwnck> >>>>> >>>>> >>>>> >>>>> *Tips* >>>>> *- Show keyboard shortcuts*: press while not editing text. You >>>>> can also check out the upstream docs >>>>> <https://docs.gitlab.com/ce/workflow/shortcuts.html>. >>>>> *- Mark as duplicate*: Use quick actions in a new comment i.e. >>>>> "/duplicate #issue_number". If yo
Re: [GitLab] Projects moved, tips of the week and question of the week
It is not same, is it? I want to receive emails that are sent to commits-list: https://mail.gnome.org/archives/commits-list/ Email is sent also for gitlab projects, but problem is that you can not subscribe to these projects. On Tue, Feb 6, 2018 at 3:04 PM, Carlos Soriano <csori...@gnome.org> wrote: > Hello, > > This is a built in feature in GitLab. Feel free to subscribe to the RSS > for a project in the commits view. For example here in Nautilus > <https://gitlab.gnome.org/GNOME/nautilus/commits/master>, click the > "wifi"/RSS symbol. > > Cheers > > > On 6 February 2018 at 13:45, Alberts Muktupāvels < > alberts.muktupav...@gmail.com> wrote: > >> Hi, >> >> question about commits-list: >> https://mail.gnome.org/mailman/listinfo/commits-list >> >> Is there any plan to restore option to subscribe to commits for projects >> that has moved to gitlab? >> >> >> On Wed, Jan 24, 2018 at 7:14 PM, Carlos Soriano <csori...@gnome.org> >> wrote: >> >>> Hello all, >>> >>> Today we hit a milestone, three of the biggest projects in GNOME has >>> been migrated, most of our core apps has been migrated, and with this all >>> the projects that were part of the deal with GitLab has been migrated. >>> >>> So allow me to do a short clap . >>> >>> *Projects migrated today* >>> >>> - GNOME Shell <https://gitlab.gnome.org/GNOME/gnome-shell> >>> - Mutter <https://gitlab.gnome.org/GNOME/mutter> >>> - GNOME Software <https://gitlab.gnome.org/GNOME/gnome-software> >>> - GNOME Contacts <https://gitlab.gnome.org/GNOME/gnome-contacts> >>> - GNOME Tweaks <https://gitlab.gnome.org/GNOME/gnome-tweaks>, >>> previously known as gnome-tweak-tool >>> - gnome-themes-extra <https://gitlab.gnome.org/GNOME/gnome-themes-extra>, >>> previously known as gnome-themes-standard >>> - GNOME Characters <https://gitlab.gnome.org/GNOME/gnome-characters> >>> - D-Feet <https://gitlab.gnome.org/GNOME/d-feet> >>> - libwnck <https://gitlab.gnome.org/GNOME/libwnck> >>> >>> >>> >>> *Tips* >>> *- Show keyboard shortcuts*: press while not editing text. You can >>> also check out the upstream docs >>> <https://docs.gitlab.com/ce/workflow/shortcuts.html>. >>> *- Mark as duplicate*: Use quick actions in a new comment i.e. >>> "/duplicate #issue_number". If you want to apply a label such as >>> "duplicate", you can also use "~label_name". Read more about quick >>> actions <https://docs.gitlab.com/ee/user/project/quick_actions.html> in >>> the upstream docs. >>> *- Update a MR*: Simply force push the branch with "git push -f". Read >>> more about the workflow for GNOME in our docs >>> <https://wiki.gnome.org/GitLab#GitLab_workflow_for_code_contribution>. >>> >>> *Question of the week* >>> >>> Since the question from the previous week didn't reach a clear >>> agreement, let's try a last effort on it, since it's the only one that we >>> will most probably cannot revert in short term. >>> >>> The discussion is about what name to use for our groups, specifically >>> for the current GNOME group <https://gitlab.gnome.org/GNOME>. If you >>> agree GNOME is a great name and the issues raised are not that much of an >>> issue, please say so too. Comment your thoughts and ideas on the >>> discussion. <https://gitlab.gnome.org/Infrastructure/GitLab/issues/99> >>> >>> Cheers, >>> Carlos Soriano >>> >>> ___ >>> desktop-devel-list mailing list >>> desktop-devel-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list >>> >> >> >> >> -- >> Alberts Muktupāvels >> > > -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
Hi, question about commits-list: https://mail.gnome.org/mailman/listinfo/commits-list Is there any plan to restore option to subscribe to commits for projects that has moved to gitlab? On Wed, Jan 24, 2018 at 7:14 PM, Carlos Soriano <csori...@gnome.org> wrote: > Hello all, > > Today we hit a milestone, three of the biggest projects in GNOME has been > migrated, most of our core apps has been migrated, and with this all the > projects that were part of the deal with GitLab has been migrated. > > So allow me to do a short clap . > > *Projects migrated today* > > - GNOME Shell <https://gitlab.gnome.org/GNOME/gnome-shell> > - Mutter <https://gitlab.gnome.org/GNOME/mutter> > - GNOME Software <https://gitlab.gnome.org/GNOME/gnome-software> > - GNOME Contacts <https://gitlab.gnome.org/GNOME/gnome-contacts> > - GNOME Tweaks <https://gitlab.gnome.org/GNOME/gnome-tweaks>, previously > known as gnome-tweak-tool > - gnome-themes-extra <https://gitlab.gnome.org/GNOME/gnome-themes-extra>, > previously known as gnome-themes-standard > - GNOME Characters <https://gitlab.gnome.org/GNOME/gnome-characters> > - D-Feet <https://gitlab.gnome.org/GNOME/d-feet> > - libwnck <https://gitlab.gnome.org/GNOME/libwnck> > > > > *Tips* > *- Show keyboard shortcuts*: press while not editing text. You can > also check out the upstream docs > <https://docs.gitlab.com/ce/workflow/shortcuts.html>. > *- Mark as duplicate*: Use quick actions in a new comment i.e. > "/duplicate #issue_number". If you want to apply a label such as > "duplicate", you can also use "~label_name". Read more about quick actions > <https://docs.gitlab.com/ee/user/project/quick_actions.html> in the > upstream docs. > *- Update a MR*: Simply force push the branch with "git push -f". Read > more about the workflow for GNOME in our docs > <https://wiki.gnome.org/GitLab#GitLab_workflow_for_code_contribution>. > > *Question of the week* > > Since the question from the previous week didn't reach a clear agreement, > let's try a last effort on it, since it's the only one that we will most > probably cannot revert in short term. > > The discussion is about what name to use for our groups, specifically for > the current GNOME group <https://gitlab.gnome.org/GNOME>. If you agree > GNOME is a great name and the issues raised are not that much of an issue, > please say so too. Comment your thoughts and ideas on the discussion. > <https://gitlab.gnome.org/Infrastructure/GitLab/issues/99> > > Cheers, > Carlos Soriano > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Release team now using gnome-build-meta repository, not JHBuild
On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño) <m...@3v1n0.net> wrote: > Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto: > > On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote: > >> Were you actually using JHBuild to run integrated system components > >> (gnome-shell, gnome-session)? If so, how? I was not aware that that > >> was even possible nowadays. > >> > >> When developing these components, > > > > Sorry, trying again > > > > When developing components like gnome-shell and gnome-session, I've > > found myself working in a VM and installing directly into /usr/bin. It's > > the only way I'm aware of that works. (You can try /usr/local, but then > > you have to hack executable paths in several projects) > > As said it's not like that, I'm just running everyday this to run > gnome-shell > > jhbuild run env XDG_SESSION_TYPE=wayland \ > XDG_RUNTIME_DIR=/tmp/jhbuild-runtime \ > dbus-run-session gnome-shell --wayland \ >--display-server > > Same works when using X11 or gnome-session (just replacing the command). > So it looks like there's nothing similar to that yet. > > Maybe JHBuild could be a bst client for building only? > Seems that everyone has their own usage... I have multiseat setup. On my main seat I do development and testing is done on second seat. I have configured JHBuild to make it possible to build multiple versions. For example `jhbuild build` will build/rebuild current development version - 3.28 and `VERSION=3.26 jhbuild build` will rebuild 3.26 modulset. On second seat I can easily login in 3.28 session and if needed also in 3.26. I regularly do `jhbuild build` and/or `VERSION=3.26 jhbuild build` to update with newest changes for development and last stable version. I also use `VERSION=3.26 jhbuild checkbranches -b gnome-3-26` to make sure that stable version build from correct branch. And mostly I do update jhbuild modulesets if change is simple enough that I am sure that it is correct and wont break anything... Mentioned at-spi2-core "problem". I am pretty sure that I have done `jhbuild done` in November and I don't remember that build has been broken because of at-spi2-core. Any chance that jhbuild simply has re-used previously generated configure file?: https://git.gnome.org/browse/jhbuild/tree/jhbuild/modtypes/autotools.py#n111 To me this looks like tool that was able to do task x is replaced with tool that is supposed to do y... Following this thread it clear that BuildStream will never provide same functionality. So how developers are supposed to test fixes/changes to apps? I could easily restart re-built app in jhbuild session or logout and login to test bigger changes. How am I supposed to achieve something similar with BuildStream? Will I need to build VM images, restart VM and then test my changes? Sorry if that already is posted somewhere, but is there at least some kind of migration guide/tutorial? -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JHBuild
Hi, I pushed wip/muktupavels/force-non-srcdir-build branch to jhbuild. Can someone review few commits? It adds force-non-srcdir-builds attribute support to autotools and adds this attribute to mozjs52 and colord modules. On Tue, Aug 1, 2017 at 11:16 AM, Alberts Muktupāvels < alberts.muktupav...@gmail.com> wrote: > colord has build-api wrapper, but that does not help because of meson. I > prefer to build in srcdir that meson does not like: > Source and build directories must not be the same. Create a pristine build > directory. > Using force-non-srcdir-builds attribute allows me to build colord once. Next time it will fail with "Trying to run Meson on a build directory that has already been configured", but that is better then current situation. Same problem with new mozjs, it does not build in src dir. > Also fixed by forcing non srcdir build. -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
JHBuild
Hi, is there anything that could be done to make building with JHBuild better? jhbuild build This command I use at least few times in week and almost always there are problems. :( Mostly I am using it to update existing modules, but sometimes I start fresh by deleting checkout and install directories. This time it failed quite fast with build failure in pango. New source files was added to Makefile.am, but not to meson.build. If project has decided to support both then please test build with both build systems. Fixing that did not help a lot... Now colord fails to build. It is ported to meson, but no one has updated jhbuild modulesets. Can someone please update it? colord has build-api wrapper, but that does not help because of meson. I prefer to build in srcdir that meson does not like: Source and build directories must not be the same. Create a pristine build directory. If meson does not support building in src dir then is it possible to force jhbuild to use builddir with meson even if I have configured to build in src dir? Same problem with new mozjs, it does not build in src dir. Then build failure with gst-plugins-bad. It fails 100% if I try to update it. I need first uninstall it: jhbuild uninstall gst-plugins-bad Is there something I can do about it? Workaround? -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver: Up for grabs?
On Wed, Jul 27, 2016 at 5:05 PM, Ikey Doherty <michael.i.dohe...@intel.com> wrote: > > For long time I already want/plan to merge gnome-screensaver into > > gnome-flashback. It will give more freedom to make needed changes > > without affecting any other users and/or sessions that still use > > gnome-screensaver. So I guess I can say that we are not interested in > > GNOME Screensaver as standalone module. > > ..So.. you're forking it, contrary to what you said above. Into your own > gnome-flashback component. > With forking I mostly was thinking about gnome-settings-daemon - it is maintained and used by GNOME. So I don't want to fork it to just add one or two small changes and then maintain it by cherry-picking probably all changes from original project. -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gettext
On Wed, May 18, 2016 at 9:39 AM, <philip.chime...@gmail.com> wrote: > On Tue, May 17, 2016 at 2:36 AM Daiki Ueno <u...@gnu.org> wrote: > >> philip.chime...@gmail.com writes: >> >> > After trying it out, it's very unfortunate that msgfmt doesn't have an >> > argument allowing you to specify a custom ITS rule; it only detects >> > ones that have been installed into the Gettext data directories. >> >> The xgettext's --its option was originally added for testing purpose (to >> check if a given ITS file works as expected). The suggested way to >> specify custom ITS rules is to install those files in >> /usr/share/gettext, because of ... >> >> > Also, if you use xgettext's --its option to specify a custom ITS rule, >> > then it seems not to pick up translatable strings from C sources >> > anymore; but without it, it won't pick them up from the XML >> > files. I'll check again tomorrow and otherwise report this as a bug. >> >> ... this. It is the same limitation that -L, -k, --flags options are >> effective for all input files. There was a discussion to support >> per-file options, but it is not implemented yet: >> http://article.gmane.org/gmane.comp.gnu.gettext.bugs/863 >> >> Anyway, thanks for writing up the document! >> > > Thanks for the clarification! > > Do you know of an Autotools workflow with xgettext / msgfmt that could > replace the one I described with itstool in the document? > > I'm thinking specifically of a case where the XML format is ad-hoc to the > package (such as gtksourceview), and therefore the ITS rule can't be > installed into /usr/share/gettext because then the package would require > itself to be installed in order to be able to run make dist, for example. > > Thanks, > Philip > Probably related bug: https://bugzilla.gnome.org/show_bug.cgi?id=755466 -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
session-dependent defaults in GSettings
Hi, I have seen few commits with following message - There are plans to add session-dependent defaults to GSettings (based on the newly standardized XDG_CURRENT_DESKTOP); Has someone actually started to work on this? Is there some info, page or something like that where I could get more information and follow its progress? Thanks! -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
maintainership of gnome-screensaver and notification-daemon
Hi, last releases for these modules are two years old. These modules are no longer used in GNOME, right? Modules are still used in unofficial GNOME Flashback session so I would like take over maintainership of these modules. I sent mail to current maintainers of notification-daemon one week ago. Till now I have not received response. -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: End Session Dialog
Hi, I have created patch and bug report for this: https://bugzilla.gnome.org/show_bug.cgi?id=738264 This patch will not require any changes to GNOME Shell. Please consider applying this patch to gnome-session. On Fri, Sep 19, 2014 at 8:26 PM, Alberts Muktupāvels alberts.muktupav...@gmail.com wrote: Hi, question to gnome-session and gnome-shell developers about End Session dialog. Currently gnome-session expect that End Session Dialog is available on org.gnome.Shell. Can we change it so it does not require org.gnome.Shell for that dialog? I would suggest to change this: #define SHELL_END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog #define SHELL_END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog to: #define END_SESSION_DIALOG_NAME org.gnome.SessionManager.EndSessionDialog #define END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog #define END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog I am not expecting that someone of you are going to do it. I am ready to prepare patches for gnome-session and gnome-shell for this change, but before doing it I would like to know if patches are welcome for this. Thanks! -- Alberts Muktupāvels -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
End Session Dialog
Hi, question to gnome-session and gnome-shell developers about End Session dialog. Currently gnome-session expect that End Session Dialog is available on org.gnome.Shell. Can we change it so it does not require org.gnome.Shell for that dialog? I would suggest to change this: #define SHELL_END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog #define SHELL_END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog to: #define END_SESSION_DIALOG_NAME org.gnome.SessionManager.EndSessionDialog #define END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog #define END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog I am not expecting that someone of you are going to do it. I am ready to prepare patches for gnome-session and gnome-shell for this change, but before doing it I would like to know if patches are welcome for this. Thanks! -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: End Session Dialog
On Fri, Sep 19, 2014 at 10:27 PM, Owen Taylor otay...@redhat.com wrote: On Fri, 2014-09-19 at 20:26 +0300, Alberts Muktupāvels wrote: question to gnome-session and gnome-shell developers about End Session dialog. Currently gnome-session expect that End Session Dialog is available on org.gnome.Shell. Can we change it so it does not require org.gnome.Shell for that dialog? What's your reasoning for why you want this to be done? I am trying to keep alive old classic / fallback session now known as Flashback session (metacity, gnome-panel). To show End Session Dialog we need to connect to org.gnome.Shell. That works, but now applications thinks that GNOME Shell is running... -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: End Session Dialog
On Fri, Sep 19, 2014 at 11:04 PM, Owen Taylor otay...@redhat.com wrote:
On Fri, 2014-09-19 at 22:49 +0300, Alberts Muktupāvels wrote:
On Fri, Sep 19, 2014 at 10:27 PM, Owen Taylor otay...@redhat.com
wrote:
On Fri, 2014-09-19 at 20:26 +0300, Alberts Muktupāvels wrote:
question to gnome-session and gnome-shell developers about
End Session
dialog.
Currently gnome-session expect that End Session Dialog is
available on
org.gnome.Shell. Can we change it so it does not require
org.gnome.Shell for that dialog?
What's your reasoning for why you want this to be done?
I am trying to keep alive old classic / fallback session now known as
Flashback session (metacity, gnome-panel). To show End Session Dialog
we need to connect to org.gnome.Shell. That works, but now
applications thinks that GNOME Shell is running...
This is tricky - GNOME Shell is a system component of GNOME, and
dependencies on it aren't limited to gnome-session - I also, for
example, see uses of GNOME SHell D-Bus interfaces in
gnome-control-center and gnome-settings-daemon.
I am right now running Flashback session without GNOME Shell.
gnome-settings-daemon and gnome-control-center works without it. So at
least for now I don't see problem here.
(Do global keybindings work without GNOME Shell running? I thought they
relied on GNOME Shell for that for now.)
Probably not, but that is other problem that I will have to deal with.
My opinion is that the Fllashback cannot increase the maintenance load
of GNOME ... there's a reason we wanted to get rid of fallback mode.
It is not my intention. I attached example.patch for gnome-session. Then we
need patch for gnome-shell to export EndSessionDialog interface on
org.gnome.SessionManager.EndSessionDialog not on org.gnome.Shell. It does
not look like it would increase the maintenance load, but would allow
Flashback session to show that dialog without using org.gnome.Shell.
--
Alberts Muktupāvels
From 2abdf9f887164998863298aa55a3f12705132524 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alberts=20Muktup=C4=81vels?= alberts.muktupav...@gmail.com
Date: Fri, 19 Sep 2014 23:23:11 +0300
Subject: [PATCH] example
---
gnome-session/gsm-manager.c | 3 ---
gnome-session/gsm-shell.c | 12 ++--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/gnome-session/gsm-manager.c b/gnome-session/gsm-manager.c
index 596db92..48176ad 100644
--- a/gnome-session/gsm-manager.c
+++ b/gnome-session/gsm-manager.c
@@ -3018,9 +3018,6 @@ static void
show_shell_end_session_dialog (GsmManager *manager,
GsmShellEndSessionDialogType type)
{
-if (!gsm_shell_is_running (manager-priv-shell))
-return;
-
gsm_shell_open_end_session_dialog (manager-priv-shell,
type,
manager-priv-inhibitors);
diff --git a/gnome-session/gsm-shell.c b/gnome-session/gsm-shell.c
index da9aec3..244763e 100644
--- a/gnome-session/gsm-shell.c
+++ b/gnome-session/gsm-shell.c
@@ -36,8 +36,9 @@
#define SHELL_PATH /org/gnome/Shell
#define SHELL_INTERFACE org.gnome.Shell
-#define SHELL_END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog
-#define SHELL_END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog
+#define END_SESSION_DIALOG_NAME org.gnome.SessionManager.EndSessionDialog
+#define END_SESSION_DIALOG_PATH /org/gnome/SessionManager/EndSessionDialog
+#define END_SESSION_DIALOG_INTERFACE org.gnome.SessionManager.EndSessionDialog
#define GSM_SHELL_DBUS_TYPE_G_OBJECT_PATH_ARRAY (dbus_g_type_get_collection (GPtrArray, DBUS_TYPE_G_OBJECT_PATH))
@@ -574,7 +575,6 @@ gsm_shell_open_end_session_dialog (GsmShell *shell,
g_warning (Could not connect to the shell: %s,
error-message);
g_error_free (error);
-return FALSE;
}
if (shell-priv-end_session_open_call != NULL) {
@@ -588,9 +588,9 @@ gsm_shell_open_end_session_dialog (GsmShell *shell,
DBusGProxy *proxy;
proxy = dbus_g_proxy_new_for_name (shell-priv-bus_connection,
- SHELL_NAME,
- SHELL_END_SESSION_DIALOG_PATH,
- SHELL_END_SESSION_DIALOG_INTERFACE);
+ END_SESSION_DIALOG_NAME,
+ END_SESSION_DIALOG_PATH,
+ END_SESSION_DIALOG_INTERFACE);
g_assert (proxy != NULL);
--
2.1.0
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https
Re: End Session Dialog
On Fri, Sep 19, 2014 at 11:45 PM, Alberts Muktupāvels
alberts.muktupav...@gmail.com wrote:
On Fri, Sep 19, 2014 at 11:04 PM, Owen Taylor otay...@redhat.com wrote:
On Fri, 2014-09-19 at 22:49 +0300, Alberts Muktupāvels wrote:
On Fri, Sep 19, 2014 at 10:27 PM, Owen Taylor otay...@redhat.com
wrote:
On Fri, 2014-09-19 at 20:26 +0300, Alberts Muktupāvels wrote:
question to gnome-session and gnome-shell developers about
End Session
dialog.
Currently gnome-session expect that End Session Dialog is
available on
org.gnome.Shell. Can we change it so it does not require
org.gnome.Shell for that dialog?
What's your reasoning for why you want this to be done?
I am trying to keep alive old classic / fallback session now known as
Flashback session (metacity, gnome-panel). To show End Session Dialog
we need to connect to org.gnome.Shell. That works, but now
applications thinks that GNOME Shell is running...
This is tricky - GNOME Shell is a system component of GNOME, and
dependencies on it aren't limited to gnome-session - I also, for
example, see uses of GNOME SHell D-Bus interfaces in
gnome-control-center and gnome-settings-daemon.
I am right now running Flashback session without GNOME Shell.
gnome-settings-daemon and gnome-control-center works without it. So at
least for now I don't see problem here.
(Do global keybindings work without GNOME Shell running? I thought they
relied on GNOME Shell for that for now.)
Probably not, but that is other problem that I will have to deal with.
My opinion is that the Fllashback cannot increase the maintenance load
of GNOME ... there's a reason we wanted to get rid of fallback mode.
It is not my intention. I attached example.patch for gnome-session. Then
we need patch for gnome-shell to export EndSessionDialog interface on
org.gnome.SessionManager.EndSessionDialog not on org.gnome.Shell. It does
not look like it would increase the maintenance load, but would allow
Flashback session to show that dialog without using org.gnome.Shell.
And it looks like patch for gnome-shell will be even simpler. Only one
extra line, see attachment. Now with patched gnome-session and gnome-shell
end session dialog works fine in GNOME Shell and GNOME Flashback sessions.
Should I create properly formatted patches and bug reports? It would be
nice if this could be included when 3.16 development starts.
--
Alberts Muktupāvels
From 49b7938aa310dccb303a8f9600dcd5bb9c601562 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alberts=20Muktup=C4=81vels?= alberts.muktupav...@gmail.com
Date: Sat, 20 Sep 2014 00:40:03 +0300
Subject: [PATCH] example 2
---
js/ui/endSessionDialog.js | 2 ++
1 file changed, 2 insertions(+)
diff --git a/js/ui/endSessionDialog.js b/js/ui/endSessionDialog.js
index 966bae2..de7084c 100644
--- a/js/ui/endSessionDialog.js
+++ b/js/ui/endSessionDialog.js
@@ -373,6 +373,8 @@ const EndSessionDialog = new Lang.Class({
this._dbusImpl = Gio.DBusExportedObject.wrapJSObject(EndSessionDialogIface, this);
this._dbusImpl.export(Gio.DBus.session, '/org/gnome/SessionManager/EndSessionDialog');
+
+Gio.DBus.session.own_name('org.gnome.SessionManager.EndSessionDialog', Gio.BusNameOwnerFlags.REPLACE, null, null);
},
_onDestroy: function() {
--
2.1.0
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
