Re: Moving final mailman lists over to discourse
Hi, On Thu, Sep 29, 2022 at 10:49 AM Neil McGovern wrote: > Hi folks, > > On Mon, 2022-08-22 at 14:36 +0100, Neil McGovern wrote: > > > As mentioned about three years ago, there's a desire to retire > > > mailman > > > and its dependencies on python2. Discussion is now happening on > > > discourse.gnome.org. > > > > > > Over the coming month, I'll be going through each list that > > > remains, > > > seeing if they're still alive and moving them over [0] > > > > > I've gone through every mailing list that we host, and broadly split > them into two categories - lists that can be closed and ones that > should be migrated to discourse. > > For those which should close, they've had very low activity (in some > cases, zero...). For those that should move, I've made sure that > there's tags in place so people can filter for a specific subject if > they want. Please see the attached. Travel Committee didn’t have any activity during the pandemic travel bans, but we are using it again now that we’re back to finding travel. Can you please migrate it? Thanks, Meg > > > For both, the archives will be preserved, but they won't accept or > distribute any new mail after the end of October. > > Again, as a reminder, if you have any automation that's posting to > mailing lists, let me know (Thanks to the release team for having > already done so :P). > > Thanks, > Neil > -- > Neil McGovern > Executive Director, The GNOME Foundation > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GJS Docs now Hosted on gnome.org
Hi,
On Wed, Jun 26, 2019 at 4:47 AM Andre Klapper wrote:
> On Tue, 2019-06-25 at 08:47 -0400, makep...@firemail.cc wrote:
> > On 2019-06-24 21:06, meg ford wrote:
> > > https://gjs-docs.gnome.org/
>
> Just for the records:
>
> In a perfect world, this would be on https://developer.gnome.org/
> instead.
>
> But understandable because in reality, the site infrastructure
> ("library-web") is rather unmaintained and falling apart.
> See e.g. https://gitlab.gnome.org/Infrastructure/library-web/issues/12
> or https://bugzilla.gnome.org/show_bug.cgi?id=785522
I'm going to make a pull request to update the links to the GJS docs on
developer.gnome.org soon. I thought moving the GJS docs to GNOME infra was
a good first step towards making sure we can easily maintain them. If
there's anything else the Documentation team would like me to do let me
know. If nothing else we can talk about it at GUADEC. Of course it's
important to include Philip in any of those conversations since he is the
person who maintains the code and Docker file for the site. I just picked
it up getting it to run on OpenShift because I do a lot of cloud dev so it
was simple for me to do.
Cheers,
Meg
>
>
> andre
> --
> Andre Klapper | ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GJS Docs now Hosted on gnome.org
Hi, This is just a quick note to let everyone know that I put the GJS Docs site up on GNOME's OpenShift instance. Philip asked me to put it up on a server after the old site became unmaintained, and Andrea Veri suggested it would be easier to host it on GNOME. Thanks to both of them for their assistance! The site is live at https://gjs-docs.gnome.org/ Happy Hacking :) Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnu/Gnome/Linux/Ubuntu? I'm confused
Hi, On Wed, Apr 12, 2017 at 11:36 AM, J Wilson via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > To whom it may concern, > > In late February I was forced into switching to a Free software OS, > because Windows Vista is no longer supported and of course this also > applied to Google which seemed to have forced my Firefox browser to stop > working a while ago too. However, to cut a long story short, I opted for > the Ubuntu Desktop although I also downloaded a couple of others like Mint > & KDE to look at too and was daunted by what appeared to be a blank desktop. > > And although this seemed to work fine to start with, I seem to have > developed a few snags, including not starting normally, but going into > 'boot mode' every day; and losing any responses to 'pings' on the icon for > Ubuntu Software window. Although software 'update' seems to be working > independently. However, as I was just reading that this package was > actually copied from Gnome and I've found your email address, I thought > I'd ask you if you have had other reports of such problems and how to fix > it? > > I have wondered if it was anything to do with me using another programme > which I also cannot access now, but it was some kind of C+ or C 'cleaner'. > So perhaps it has dumped some of my files by mistake. And when rebooting I > keep getting told that ubuntu-vg can't be found, or lvmetad either; along > with LSB Armor? too. Again I assume that you might be able to tell me what > to do to fix this as the original programmes may have been written by you. > I have found another few 'quirks' that are annoying but this is the worst > at the moment. > I would suggest that you look for a Linux User group in your area. If you contact them and ask for help they may have someone who will help you work through your issues either in person or over a mailing list. You can also ask for help with other issues you may encounter as a Linux new user. Another option is to search for your issues on the Ubuntu forums ( https://askubuntu.com/ or https://ubuntuforums.org/) and see if you can find answers that way. Meg Ford > > However, if I have any criticisms of the wonders of Free Software, it is > the lack of simplicity of use although i appreciate that it seems to have > been built with 'expert' users in mind, not 'plebs' like me. So is there > anything you can do to improve that too? > > Yours Faithfully > > Mr J Wilson > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Logo Licensing
Hi, Recently the licensing of the GNOME logo has come up in board discussions. The asset is currently trademarked but we do not have a license for it as far as we can determine [0]. We would like to propose licensing the asset with dual LGPLv3/CC-BY-SA-4.0. This is similar to the license used by the adwaita-icon-theme. Before moving forward with this, we decided to ask the community for feedback regarding the proposal. Does anyone have comments/suggestions/objections? Thanks, Meg [0] https://www.gnome.org/logo-and-trademarks/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Reminder | CfP deadline for LAS GNOME this Sunday
Hi everyone, This is a quick reminder that the deadline to submit a paper to LAS GNOME is this Sunday, July 31st. We encourage you to submit your talk now: http://las.gnome.org/submit-your-talk/ LAS GNOME will be held in Portland, Oregon on September 19 - 23rd and is the conference to attend if you want to create a business around Linux-based applications, release your applications to multiple distributions at the same time, and/or create the conditions necessary to reach a wider audience for your current Linux apps. Possible topics include, but are not limited to: - Ecosystem: business, legal, community, and social issues - Platforms: deep low-level topics around hardware, drivers, and tools - Distribution: collaborating with established distributions (like OpenSuse), inter-distribution cooperation, QA and continuous integration. - Development: toolkits, X/Wayland, security, runtimes, SDK, development tools. Proposals by newcomers and experienced speakers are welcomed alike. When submitting your proposal, please keep in mind that talk slots are 45 minutes long. Best, The LAS GNOME Committee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bugfix in gnome-sound-recorder
Hi, Last week I got a report about a bug which broke the waveforms in gnome-sound-recorder in 3.18.1. The problem was caused by improvements which made GStreamer faster and uncovered an uncaught exception in my code. Since 3.18.1 was the last release I made for 3.18, and I've never had to do a bugfix, I don't know how to proceed. Is there some way to distribute a version with the patch? Do I need to file patches to downstream versions? Thanks very much for your time! Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Mon, Sep 1, 2014 at 8:43 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: On Sep 1, 2014 6:28 PM, meg ford meg...@gmail.com wrote: Hey, On Mon, Sep 1, 2014 at 8:04 PM, Michael Catanzaro mcatanz...@gnome.org wrote: the C++, Python, and JS examples in gnome-devel-demos. If nobody volunteers to review them before 3.16, then I think they should be removed. I really don't think you should remove them. Having something there is better than nothing, especially given that most application developers aren't using C or Vala. I beg to differ, vala is very popular. More popular than JavaScript. Every thread in Reddit on GTK+ always ends up talking about how awesome Vala is. Within our ecosystem, yes, but outside of GNOME I know one developer who uses Vala. Presumably those developers who are already part of the community are more likely to read the docs for C or source code if there isn't a Vala example or an example for the language they are using. So I suppose it depends on who you are targeting. ElementaryOs uses Vala exclusively. The folks at Yorba use Vala. We spent time talking about Vala at West Coast Hackfest. Like it or not, it is very popular. I don't have any problem with Vala, but I don't think it's as widely used as Python or JS. However, I'm not interested in having a debate here, I was just telling you my opinion as an app developer. As they say, since I'm not volunteering to write the docs, it's ultimately up to the people who put in the time. Meg We never talk about python or JavaScript. Sri Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
On 7 March 2014 17:45, meg ford meg...@gmail.com wrote: It would also be awesome if whoever takes the lead on this makes sure that the functionality we are documenting actually works. If we want devs to be able to write GNOME apps then having documentation that matches the functionality they can access using the the language application developer docs are showing seems pretty key to me. Sure, this is one of the main motivations for rebasing the documentation generator on top of introspection data. There are situations where bindings exist and in fact the functions don't work or the return values need to be accessed in odd ways (for example as by array index). Of course having the documentation is helpful because at least you don't have to mentally translate from C or read the raw gir files in order to figure out if the function should work, but there are some situations in which the documentation will need to be altered to reflect the reality. Regards, Tomeu On Fri, Mar 7, 2014 at 8:06 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On 4 March 2014 16:58, Frederic Peters fpet...@gnome.org wrote: Hey, It's been proved again in recent hackfests, we have a really great team writing user documentations, and thanks have to be given to Shaun, and now Kat, for coordinating the effort. On the other hand we have absolutely no coordination for developer docs, I maintain developer.gnome.org with the little time I have, Aleksander helps with Devhelp, there are some punctual changes from various persons, David maintains gnome-devel-docs, Tomeu did work on generating python documentation from gobject-introspection a while ago, Giovanni did it for gjs recently, Jon improved markdown support in gtk-doc, etc. but all this happens without coordination and it happens people step on each other's toes, and it hurts. Developer documentation will be a topic during the Developer Experience Hackfest, but I believe we will fail again to provide lasting effects if nobody takes on a coordination role. I agree coordination is needed right now. I have signed up for the hackfest because I know that there's still lots of work to do in the api doc generator and I would like to put my experience on the existing codebase to good use. But I'm a bit lost since the decisions that were agreed at the Berlin hackfest seem to have been overridden at some point and I have missed the rationale. So, are you interested? These days I do stuff that is related only peripherally to GNOME, so I'm afraid that I won't find enough time to take on the coordination. If nobody gets to propose a good plan before, I guess we'll have to have a good planning session at the start of the hackfest. Regards, Tomeu Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
On Sun, Mar 9, 2014 at 11:54 AM, Stefan Sauer enso...@hora-obscura.dewrote: I see. The pull requests would lower the barrier to fix docs. There was a lengthy discussion of this on the foundation-list last August, and a follow-up email from Karen in September regarding the Board's decision [1]. Meg [1] https://mail.gnome.org/archives/foundation-list/2013-September/msg4.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
It would also be awesome if whoever takes the lead on this makes sure that the functionality we are documenting actually works. If we want devs to be able to write GNOME apps then having documentation that matches the functionality they can access using the the language application developer docs are showing seems pretty key to me. On Fri, Mar 7, 2014 at 8:06 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On 4 March 2014 16:58, Frederic Peters fpet...@gnome.org wrote: Hey, It's been proved again in recent hackfests, we have a really great team writing user documentations, and thanks have to be given to Shaun, and now Kat, for coordinating the effort. On the other hand we have absolutely no coordination for developer docs, I maintain developer.gnome.org with the little time I have, Aleksander helps with Devhelp, there are some punctual changes from various persons, David maintains gnome-devel-docs, Tomeu did work on generating python documentation from gobject-introspection a while ago, Giovanni did it for gjs recently, Jon improved markdown support in gtk-doc, etc. but all this happens without coordination and it happens people step on each other's toes, and it hurts. Developer documentation will be a topic during the Developer Experience Hackfest, but I believe we will fail again to provide lasting effects if nobody takes on a coordination role. I agree coordination is needed right now. I have signed up for the hackfest because I know that there's still lots of work to do in the api doc generator and I would like to put my experience on the existing codebase to good use. But I'm a bit lost since the decisions that were agreed at the Berlin hackfest seem to have been overridden at some point and I have missed the rationale. So, are you interested? These days I do stuff that is related only peripherally to GNOME, so I'm afraid that I won't find enough time to take on the coordination. If nobody gets to propose a good plan before, I guess we'll have to have a good planning session at the start of the hackfest. Regards, Tomeu Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announce: Gjs documentation almost ready!
Nice job! Thanks for doing this, Giovanni! On Wed, Feb 26, 2014 at 1:44 PM, rickop...@gmail.com rickop...@gmail.comwrote: YES! Finally! ;-) Sent from MailWise http://www.mail-wise.com/ Original Message From: Giovanni Campagna scampa.giova...@gmail.com Sent: Wednesday, February 26, 2014 08:27 PM To: desktop-devel-list desktop-devel-list@gnome.org Subject: Announce: Gjs documentation almost ready! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fix wrong FSF's address in in source files
Feel free to push them for gnome-sound-recorder. I'll check in the next few days and if you haven't had a chance I will do this myself. Thanks, Meg Ford On Wed, Jan 29, 2014 at 9:14 AM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: That's the same I though in a firs't stage, but didn't want to generate problems... if after some days, there are some remaining modules to commit, I'll push them directly Thanks Hughsie! 2014-01-29 Richard Hughes hughsi...@gmail.com On 29 January 2014 15:03, Andika Triwidada and...@gmail.com wrote: Do you think all those hundreds modules need to be addressed one by one manually? I'm only talking for myself now, but I'd be surprised if any maintainer is going to say no to those patches. If I were you, I'd just commit the changes, and apologise to any maintainers that complained. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential GNOME IDE
Hi Michael, On Sat, Jan 4, 2014 at 8:53 AM, Michael Ikey Doherty michael.i.dohe...@intel.com wrote: As promised, preliminary mockup of what I meant with the sidebar: https://plus.google.com/+IkeyDoherty/posts/cJF7N9djmZz Looks good! I'd recommend that you ask Allan Day for some feedback since he made the initial designs for the IDE, as posted on the GNOME Apps wiki (he may respond here, though I'm not sure how active he is on the mailing list). Also, you may want to contact Christian Hergert directly to see what his plans are for gnome-builder right now. As you mentioned, prototyping changes you want to see, maybe using gnome-builder as the base for a branch, and following up on Sebastian Wilmet's suggestions are all great ideas for moving forward, IMHO. I think the key to working on a new GNOME app is just communicating with all the parties involved so there isn't any unnecessary duplication of work that happens. Awesome that you are considering taking this on! Good luck, and I'm looking forward to this (especially if you support GJS :)! Cheers, Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential GNOME IDE
On Fri, Jan 3, 2014 at 3:12 PM, Sébastien Wilmet swil...@gnome.org wrote: On Fri, Jan 03, 2014 at 08:02:40PM +, Michael Ikey Doherty wrote: Heh, true enough. I must admit when I saw the mockup artwork for the potential GNOME IDE I somewhat drooled. Is that project still a-go, and if so is there somewhere where I could provide a little help? You might want to ask on #gnome-design to see if they are aware of anyone working on the IDE. I remember hearing a little about Christian Hergert's gnome-builder project but other than that I don't believe the IDE has gone beyond the mockup stage. But I haven't been on irc much lately, so I may be wrong :) Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME coding guidelines doc gone?
Hi, On Sun, Jun 23, 2013 at 2:39 PM, Stefan Sauer enso...@hora-obscura.dewrote: On 06/16/2013 12:24 PM, Sébastien Wilmet wrote: Hello, On Sun, Jun 16, 2013 at 11:33:53AM +0200, Stefan Sauer wrote: once upon a time we hadhttp://developer.gnome.org/doc/guides/programming-guidelines/book1.html; http://developer.gnome.org/doc/guides/programming-guidelines/book1.html. We link to that from the gstreamer manual as a recommended reading. Can anyone suggest a replacement? It is still available at:ftp://ftp.gnome.org/pub/GNOME/teams/docs/devel/guides/programming_guidelines/ But I don't know if it is exactly the same document as was available at developer.gnome.org. Sébastien Thanks for finding it. I wonder where the docbook version went. Linking to a ps file is not that nice. Do we want to republish this? Something that sits next to the Platform Overview at https://developer.gnome.org/. https://developer.gnome.org/ I linked to it in the working version of the new gnome-devel-docs [1], so it should be included in the reorganized developer.gnome.org when it's finished. I'll look for a docbook version. Of course, if Federico wants to link to it as part of the revamped Platform Overview that would be nice as well :) I don't see it there, though. Meg Ford [1]https://git.gnome.org/browse/gnome-devel-docs/tree/tutorials/C/first-gnome-application.page?h=wip/reorganization Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME coding guidelines doc gone?
Hi, On Thu, Jun 20, 2013 at 8:13 PM, Sriram Ramkrishna s...@ramkrishna.mewrote: On Thu, Jun 20, 2013 at 10:25 AM, Federico Mena Quintero feder...@gnome.org wrote: On Sun, 2013-06-16 at 12:24 +0200, Sébastien Wilmet wrote: On Sun, Jun 16, 2013 at 11:33:53AM +0200, Stefan Sauer wrote: once upon a time we had http://developer.gnome.org/doc/guides/programming-guidelines/book1.html;. We link to that from the gstreamer manual as a recommended reading. Can anyone suggest a replacement? It is still available at: ftp://ftp.gnome.org/pub/GNOME/teams/docs/devel/guides/programming_guidelines/ But I don't know if it is exactly the same document as was available at developer.gnome.org. Yes, that's the correct document. It is a bit obsolete now, although it still contains good advice. Maybe we can do some kind of help hackfest to update some of our documentation during GUADEC? Federico, Allan, and I are planning a GJS Documentation BoF at GUADEC[1]. We welcome participants :) Meg https://live.gnome.org/GUADEC/2013/BOFs sri Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 11:57 AM, Allan Day allanp...@gmail.com wrote: But on non-touch screens, some people like my mom (whose eyesight is not so great these days) could also benefit from bigger icons, or at least *more contrasty* icons. Dude, they couldn't have any more contrast. Well, they could. It sounds like your mom might benefit from High Contrast, Federico, although afaik it doesn't affect the icons in the shell. The magnifier's contrast settings do; maybe try that? The other day she called me as she couldn't figure out how to increase the volume. It turns out that audio was muted, and what gnome-shell shows in that case is a dark gray audio icon with a tiny little X on its corner. The dark gray icon (around 25% gray) has very little contrast with respect to its surrounding black bar (0% gray). The apparent contrast is even less since often what you have directy below the icon is the very-lightly-colored titlebar of a window (... with a white content area), so the dark gray audio icon is hard to see. Seems like an obvious bug with the volume icon - did you file a report? This isn't a bug. He's talking about the fact that the titlebars of the windows are light-colored, and therefore the icon colors seem less distinct in comparison. Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The name of applications on GNOME 3.7.92 testing image
On Fri, Mar 22, 2013 at 1:41 PM, Mathieu Bridon boche...@fedoraproject.orgwrote: Most people I know use a word processor (MS Word, LibreOffice Writer,...) when they want to write text, even for quick things without formatting. I don't think a **simple** text editor à-la Notepad really is that useful for anybody. It might even be confusing for many people. Try to explain the difference between a word processor and a text editor for example. Usually, the next question is « But then what's the point of something that lets you type simple text, but without any formatting? » I used to use word processing programs, but now I only use Google Docs (if that counts as a word processing program), a text editor (for writing code and taking notes in class), or a note-taking application. Word processing programs are (imo) generally unwieldy, inconvenient, and don't provide enough document portability. As a student I want to have access to my documents no matter what device I am using, so I tend to choose convenience over lots of formatting options. Anyway, that's just my use case. Meg Ford I personally have no idea of the answer, as like you said, there are (or will be) dedicated apps for the interesting use cases (e.g note-taking). -- Mathieu __**_ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/desktop-**devel-listhttps://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why does killing GS with SIGHUP crash on the 2nd time?
Hi Marco,
If you need detailed explanations you can ask on the gnome-love mailing
list [1] or #gnome-love on irc.gnome.org.
Cheers,
Meg Ford
[1] https://mail.gnome.org/mailman/listinfo/gnome-love
On Mon, Mar 4, 2013 at 2:32 PM, Marco Scannadinari ma...@scannadinari.co.uk
wrote:
proxy = Gio.DBusProxy.new_for_bus_sync(
Gio.BusType.SESSION,
Gio.DBusProxyFlags.NONE,
None,
'org.gnome.Shell',
'/org/gnome/Shell',
'org.gnome.Shell',
None);
proxy.Eval('(s)', 'global.reexec_self();')
I'm really sorry - could you explain those arguments to me? - So I can
be able to reproduce them not necessarily for this program.
--
Marco Scannadinari ma...@scannadinari.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build.gnome.org
Hi Alberto, So are you saying people should list the last release as the moduleset in their ~/.jhbuildrc, and just build a current version of the module they are going to hack on? Or did I not understand what you just said? Thanks, Meg On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz ar...@gnome.org wrote: Jhbuild does build from tarballs! This is what I'm trying to say, each release has a moduleset for jhbuild with a least of each tarball (have a look at the moduleset on the ftp url I posted). You can configure your jhbuild to use that point release _and_ a single module from git. 2013/2/7 Sriram Ramkrishna s...@ramkrishna.me: OK, what you're saying is that you get all the modules you want to get except the one module you want to hack on. You get that from git, and then it should work. This makes sense because it's not likely going to run into dependency problems like you would if you get all your packages from the master packages. The downside though is that you have to do a configure;make;make install for a lot of packages. Unless there is some hack on jhbuild to build from tarballs? sri On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz ar...@gnome.org wrote: If you use the last point release moduleset[0] from tarballs I find the experience faster and less error prone. Then I configure the module I want to hack on to build from master and this usually works, in some weird cases, master requires master from another dependency, but this is very rare and addressable case. [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/ 2013/2/7 Sriram Ramkrishna s...@ramkrishna.me: I'm not sure how I missed this thread.. Regarding maintaining jhbuild up to gtk+ - I would actually like to see this up to at gnome-shell. We have a number of people who I have convinced to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated with getting jhbuild to build for them. We really should make it a goal to get an SDK for our volunteers to help fix issues. We are considering doing a jhbuild hackfest once a month for volunteers to learn and understand how to build under jhbuild and grow enough builders to make it self sustaining. But getting a certain set of modules always in buildable state is a great goal and I hope we can do this. sri On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement jean-baptiste.lallem...@canonical.com wrote: On 01/16/2013 07:39 AM, Martin Pitt wrote: Hello Colin, Hi Martin, Colin, Colin Walters [2013-01-15 15:34 -0500]: On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote: We have experimented with that a bit, by building https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/ Interesting! Looks quite useful. Are you doing anything with respect to the jhbuild sysdeps --install infrastructure or is the system package set maintained manually? Right now in our Juju charm it's a manual list: http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work well enough in principle? In Quantal, there was missing dependencies, so I went the straightest way and installed them directly. Now that I have a better understanding how jhbuild works that's something I want to reconsider for Raring and avoid maintaining them in 2 different places. -- Jean-Baptiste IRC: jibel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 12:48 PM, Philip Withnall phi...@tecnocode.co.ukwrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? Is that a rhetorical question? I think you should comment on the bug. Meg Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility team to automatically receive bugmail on a11y bug reports
Indeed, I did re-read it. Thanks :) On Mon, Aug 20, 2012 at 4:08 AM, Bastien Nocera had...@hadess.net wrote: On Sat, 2012-08-18 at 22:34 -0500, meg ford wrote: On Fri, Aug 17, 2012 at 4:44 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2012-08-17 at 11:20 +0200, Piñeiro wrote: On 08/17/2012 01:12 AM, Bastien Nocera wrote: How about having a script that would query bugs: - with the a11y keyword - that don't have the magic a11y maint alias on CC: and adds the maintainer alias for all those The rationale of this thread was about being notified of new bugs. Do you suggest to run that script every X days? Every night. I don't expect it to be any heavier than a user-triggered search. In general, as Cosimo suggested, the optimal solution would be being able to subscribe to key words (but this is not an option right now). And this is a work-around. Adding an accessibility component to gnome-control-center would just create more confusion (we already have universal access), and wouldn't allow us to carry on categorising bugs per panel. It's a no-no from me. That accessibility component was intended for accessibility bugs (ie: no keyboard navigation on X). But it is true that can be confusing (if keyboard navigation doesn't work on the universal access panel, how I classify it). Probably gnome-control-center is a bad example of a product requiring that component. Yep, but it's the one I maintain, so... I was talking to a developer today who writes automated testing systems, and he pointed out that having accessible applications makes automated testing much easier, since automated testing tools have many of the same limitations that blind users have. Since one of the goals of GNOME OS is to be easily testable, maybe you can categorize such bugs as testing bugs, if you don't want to use the a11y keyword. Might want to re-read my mail :) I want to use the a11y keyword, not an a11y component. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility team to automatically receive bugmail on a11y bug reports
On Fri, Aug 17, 2012 at 4:44 AM, Bastien Nocera had...@hadess.netwrote: On Fri, 2012-08-17 at 11:20 +0200, Piñeiro wrote: On 08/17/2012 01:12 AM, Bastien Nocera wrote: How about having a script that would query bugs: - with the a11y keyword - that don't have the magic a11y maint alias on CC: and adds the maintainer alias for all those The rationale of this thread was about being notified of new bugs. Do you suggest to run that script every X days? Every night. I don't expect it to be any heavier than a user-triggered search. In general, as Cosimo suggested, the optimal solution would be being able to subscribe to key words (but this is not an option right now). And this is a work-around. Adding an accessibility component to gnome-control-center would just create more confusion (we already have universal access), and wouldn't allow us to carry on categorising bugs per panel. It's a no-no from me. That accessibility component was intended for accessibility bugs (ie: no keyboard navigation on X). But it is true that can be confusing (if keyboard navigation doesn't work on the universal access panel, how I classify it). Probably gnome-control-center is a bad example of a product requiring that component. Yep, but it's the one I maintain, so... I was talking to a developer today who writes automated testing systems, and he pointed out that having accessible applications makes automated testing much easier, since automated testing tools have many of the same limitations that blind users have. Since one of the goals of GNOME OS is to be easily testable, maybe you can categorize such bugs as testing bugs, if you don't want to use the a11y keyword. Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Wed, Apr 25, 2012 at 8:04 PM, Shaun McCance sha...@gnome.org wrote: On Wed, 2012-04-25 at 18:38 -0400, Marina Zhurakhinskaya wrote: Hi! I'd like to propose a new lock screen as a 3.6 feature. The new lock screen will - be styled to have a uniform look and feel as the rest of GNOME Shell - be visually consistent with the look of the authentication components on the login screen - have a limited number of status icons displayed - show an indication that there are notifications or show the notifications themselves depending on the user’s preferences - allow user authentication with a password, pin, fingerprint, or smartcard The designs for the lock screen are available here: https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock I *love* the idea of showing notifications and allowing control of media playback. It's something I've wanted for a very, very long time. But I share Bhaavan's concern with having to physically drag the screen up. It's very cumbersome with a mouse. And aside from being inconvenient, without keyboard-only use it's not accessible. I also think these designs are great. This will be a really nice feature, but Shaun is right about the accessibility concerns. If keyboard-only use can be added, I think the feature would be a big +1. Meg Ford How is the PIN supposed to be set? Will that involve changes to the User Accounts panel? And while we're dealing with User Accounts and passwords, could we manage to do something about the password hint? You can set it, but it doesn't do anything useful in any software anywhere. It's kind of embarrassing to have to write that in the help. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Tue, Apr 24, 2012 at 2:54 PM, Andre Klapper ak...@gmx.net wrote: On Sun, 2012-04-22 at 20:45 +0300, Rūdolfs Mazurs wrote: Does design team use anything like meetbot? http://meetbot.debian.net/Manual.html The A11y team has a meetbot for logging meetings. They are the only team I know of that does. https://live.gnome.org/Accessibility/Meetings Meg Ford As far as I know still no bots are used for managing and logging any GNOME IRC meetings. Also see the short discussion here: https://mail.gnome.org/archives/foundation-list/2011-May/msg00072.html On a related note I once started a draft to list teams and meetings on a central wikipage as an attempt to make collaboration and contribution slightly more accessible and transparent for interested parties: https://live.gnome.org/AndreKlapper/IrcMeetings If you or anybody else feels like pushing this goal, please go ahead as I don't plan to pick this up soon again (busy with other stuff). Thanks, andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Emily, On Tue, Apr 24, 2012 at 4:19 PM, Colin Walters walt...@verbum.org wrote: Hi Emily, On Sun, 2012-04-22 at 10:27 -0400, Emily Gonyer wrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. Your criticism here has merit, but I would assert that there is some degree of this kind of insularity in many communities and organizations. A lot of communities rely implicitly on what in politics is called political capital - where to cause a change, particularly one that implies work by other people, you need to have built up some goodwill and/or reputation. I agree, this is a really intimidating part of joining the community. When I was doing my OPW internship, I was also really intimidated by the Design Team in particular -- which was bad because I was working on a project with Design Team members. Part of the reason I felt that way was that there was a discussion a lot like this one going on on the mailing list. I'm not saying that I think the situation is perfect -- sometimes I have a hard time dealing with working in the open and the criticism that goes along with it. I do think (and I've contributed to design but no one has ever called me a design team member) that there are issues in the community that need to be resolved, so I think the discussion is productive, as long as we aren't sending a negative message to newcomers or letting the community splinter over issues like this. Meg Ford In my work on the engineering side, I react completely differently to people who I know have contributed something already versus ones I don't know, because I have some assurance that by helping them solve their problem, they are likely to help me later in some way. But again, I'm not saying that there's no problem - there clearly are things we as a community could do significantly better. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, I think that this raises an important point about inclusion of accessibility features: they are often very innovative, and they enhance the experiences of average users. For example, the on-screen keyboard can be adapted for use on touch-screen devices (at least this is my understanding from discussions I had with Nohemi Fernandez while we were in Montreal) - as long as someone extends the code :) I agree with that, but we should always keep in mind who is the primary target, because sometimes people with disabilities need specific features which people without disabilities don't (imagine, for instance, a filter for the on-screen keyboard to remove unwanted keystrokes due to poor hand control). I completely agree with you here. I think that it is crucial that GNOME have a culture that supports and understands Universal design. At the same time, I also think that our accessibility community needs to put some more effort into talking to our community about access, and in communicating with the community about how to best integrate features so that they do not interfere with the average user's experience. Since the trends right now are moving away from mouse use, it might be helpful/interesting to ask ourselves whether or how cameras can be used to replace them. Are there situations in which a camera would be more useful than a touch screen or track pad? Certainly it can be for certain users with disabilities, but we might want to explore other use cases, as well. IMHO (I'm not an expert) we are still in the stone age of the machine vision based interaction and we will see great innovations in years to come. So, sure, there is much to explore and have fun! BTW: if someone is interested in playing with this, she might find interesting/useful another project called SITPLUS [1] in which we try to find other uses of camera based interaction for people with (severe) disabilities. [1] http://sitplus.appctarragona.org I -think- that for this to work properly we'd need a bunch of things: first, we need to track not only head movement but also your eyes and several facial muscles so that we can have accurate tracking and hints about your AFAIK, eViacam developers plans to add support for more facial gestures in the future. Yes. Some users requested to detect facial gestures [2] and there had been some efforts regarding blinking detection [3]. We hope to have time (and resources) to add/improve them soon. [2] https://sourceforge.net/tracker/?func=detailaid=2883828group_id=248049atid=1199431 [3] http://eviacam.git.sourceforge.net/git/gitweb.cgi?p=eviacam/eviacam;a=shortlog;h=refs/heads/blink_detect intentions. Well, this requires cameras with resolutions much higher than VGA, which is the current standard for these. Then, someone needs to figure out how to track all these elements real-time with little cpu usage. As it is, we With higher resolution cameras the behaviour would be better. But please, read again the feature proposal name Alternative input based system based on *low-cost* webcam. About performance, it is something that was always one of the priorities for eViacam developers, and the reason that the configuration wizard allows you to tweak so many parameters. can't even maintain a Mexican hat over ones head in Cheese without it lagging 3 seconds behind. And finally for this to work we'de need pretty good AI to be able to understand what you really want so that you don't end up sending a draft-mail just because you glanced at that gorgeous girl that just passed in front of you. See my previous comment about performance. Performance has always been a primary goal. In fact, is not a coincidence that we chose C/C++, used multiple threads and wrote custom code for the camera capture. And, in my experience, there is no noticeable delay in the capture - control loop is the camera is properly set up. In fact, I still remember running earlier versions on a PIII 450Hz laptop without problems. I also think that performance and facial gesture support will most likely improve faster if this is included and available to more users and developers. Sure. Best wishes, Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, I think we are missing the important bit here. Tracking your head with a webcam to drive a mouse results in a bad experience. It doesn't work even remotely well. Some users already find this feature/application really useful. Someone will, in the future, figure out how to do this properly and then it won't be called an accessibility feature but something everyone will want to use. It would be good to have it for general use for the feature. But for the moment it is just a specific accessibility tool. I think that this raises an important point about inclusion of accessibility features: they are often very innovative, and they enhance the experiences of average users. For example, the on-screen keyboard can be adapted for use on touch-screen devices (at least this is my understanding from discussions I had with Nohemi Fernandez while we were in Montreal) - as long as someone extends the code :) Since the trends right now are moving away from mouse use, it might be helpful/interesting to ask ourselves whether or how cameras can be used to replace them. Are there situations in which a camera would be more useful than a touch screen or track pad? Certainly it can be for certain users with disabilities, but we might want to explore other use cases, as well. I -think- that for this to work properly we'd need a bunch of things: first, we need to track not only head movement but also your eyes and several facial muscles so that we can have accurate tracking and hints about your AFAIK, eViacam developers plans to add support for more facial gestures in the future. intentions. Well, this requires cameras with resolutions much higher than VGA, which is the current standard for these. Then, someone needs to figure out how to track all these elements real-time with little cpu usage. As it is, we With higher resolution cameras the behaviour would be better. But please, read again the feature proposal name Alternative input based system based on *low-cost* webcam. About performance, it is something that was always one of the priorities for eViacam developers, and the reason that the configuration wizard allows you to tweak so many parameters. can't even maintain a Mexican hat over ones head in Cheese without it lagging 3 seconds behind. And finally for this to work we'de need pretty good AI to be able to understand what you really want so that you don't end up sending a draft-mail just because you glanced at that gorgeous girl that just passed in front of you. See my previous comment about performance. I also think that performance and facial gesture support will most likely improve faster if this is included and available to more users and developers. Regards, Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
