Re: Reminder: action required when updating dependencies or build options

[Nirbheek Chauhan via desktop-devel-list]

On Tue, Jan 12, 2021 at 10:21 PM Philip Withnall  wrote:
> Or, if it’s appropriate, the bot could file an issue against gnome-
> build-meta and assign the developer who’s touching meson.build to that
> issue. Or something.
>

We can reduce false positives by having it happen when the output of
`meson introspect --dependencies` or `meson introspect --buildoptions`
changes in an MR.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GnuTLS update may be required to access GIMPNet

[Nirbheek Chauhan via desktop-devel-list]

Thanks for posting about this!

On Tue, Jun 2, 2020 at 8:42 PM Michael Catanzaro 
wrote:

> Hi developers,
>
> If you are unable to connect to GIMPNet this week, you probably need to
> update GnuTLS. See below. At least Polari and other telepathy clients
> will be unable to connect without updated GnuTLS. Most distros should
> have fixes on the way already. We will try to get updated GNOME 3.34
> and 3.36 runtimes out soon for flatpak users.
>
> On Mon, Jun 1, 2020 at 9:03 am, Michael Catanzaro
>  wrote:
> > Hi distributors,
> >
> > By now, you're likely to already have at least one bug report about
> > this, but an important root CA expired yesterday, leading to a large
> > number of certificate verification failures in applications that use
> > GnuTLS [1][2]. Almost all GNOME applications, including WebKitGTK,
> > depend on GnuTLS (via glib-networking) to perform certificate
> > verification, so the impact is quite significant.
> >
> > A patch for GnuTLS is available at [3], which you are encouraged to
> > urgently apply. Fedora, Debian, and freedesktop-sdk updates are
> > already in the works. In the meantime, you'll probably notice
> > significant breakage in random places; e.g. Epiphany CI is currently
> > broken due to failure to download our adblock filters,
> > freedesktop-sdk builds were broken due to failure to download
> > gnu-hello, etc.
> >
> > Michael
> >
> > [1] https://gitlab.com/gnutls/gnutls/-/issues/1008
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1842174
> > [3] https://gitlab.com/gnutls/gnutls/-/merge_requests/1271.patch
> >
>
>
> ___
> 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: Matrix IRC bridge considered harmful

[Nirbheek Chauhan via desktop-devel-list]

On Thu, Feb 13, 2020 at 5:29 AM Christian Hergert  wrote:
>
> On 2/12/20 3:32 PM, Britt Yazel wrote:
> > Can you explain to me what the big issue with web clients are? I keep
> > hearing over and over again that developers don't want to use web
> > clients, either in browser or with Electron, but I don't recall ever
> > hearing a "why" in there.
>
> I'll repeat what I told you last month.
>
> I don't want a browser open when I work, yet I need to collaborate with
> other GNOME developers on code and platform issues. I keep Builder open,
> a terminal, and IRC. That's it.
>
> For those of our community with ADHD and similar neuro-divergence, this
> can be a necessity to get things done. The only way I get through my
> todo list is to reduce all possibilities for distraction.
>
> I suspect you wont get many people telling you that though, because to
> do so requires a level of emotional labor to share with the world their
> medical history.
>

Thanks for sharing this important perspective with us, Christian. :)

RocketChat also has a standalone Electron client, do you foresee any
issues with using that?

Personally, I don't want more Electron things on my desktop since it
kills performance on Wayland for me. In theory, we can "just" write a
native client for it; does Rocket Chat have a documented and versioned
API?

I am also hesitant for us to start using another open-core/enterprise
product where the company will be interested and enthusiastic in the
beginning because getting us to use it will be good for publicity.
Then once we're dependent on their product, they will start ignoring
us and our issues completely — leaving us with missing steps in our
workflow (hey, first-time contributor, please tick the "allow
maintainer commits checkbox") or forcing us to write bots.

I'm sure eventually we'll end up having to fork. Would rather not be
in that soup with two critical bits of infrastructure.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python 2 support in GNOME build tools

[Nirbheek Chauhan via desktop-devel-list]

On Wed, Jul 25, 2018 at 11:56 PM Sasa Ostrouska  wrote:
>
> Hi I don't know how this is relevan, but since I am building gnome for 
> Slackware, I want to advise that we will also have in Slackware next release
> Python3 as up to the 14.2 release there is only python2.
>

I'm not sure what you mean, Slackware has had Python 3 for a very long
time, fwict it has been available since 13.37 which was released in
2011: https://slackbuilds.org/repository/13.37/python/python3/

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python 2 support in GNOME build tools

[Nirbheek Chauhan via desktop-devel-list]

On Sun, Jul 15, 2018 at 4:25 PM Christoph Reiter via
desktop-devel-list  wrote:
> macOS:
>
> There still isn't any system Python 3 in sight, and could be that it never
> will happen. Homebrew works.
>

There is also a binary release (dmg) available for download on
python.org, which works quite well, so you don't need to muck around
with Homebrew to get Python 3.

I have used it, and it works well.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab CI runners for non-Linux systems

[Nirbheek Chauhan]

On Tue, May 29, 2018 at 10:30 PM 藍挺瑋  wrote:
> However, the runner I use in my GLib fork runs in a VM whose host is very
> unreliable and not suitable for use as an official CI runner. This host
crashes
> often and its uptime is usually less than 2 weeks. It also gives me random
> segfault and corrupted files sometimes. I can document steps required to
run
> GitLab CI runner on FreeBSD, so people who are able to provide machines
can
> setup a runner quickly. It is easy and can be done in about 5 commands.


It would be amazing if you could do that (maybe an email will work), so it
can be added for other projects too once we've ironed out the kinks.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series

[Nirbheek Chauhan]

On Sat, Dec 16, 2017 at 8:43 PM, Michael Biebl <mbi...@gmail.com> wrote:
> 2017-12-16 16:04 GMT+01:00 Nirbheek Chauhan <nirbheek.chau...@gmail.com>:
>> I think Debian should start using librsvg 2.41 and arch teams should
>> just deal with that reality.
>
> We can't do that unfortuanetly, as this would make librsvg
> uninstallable on half of our architectures. Which in turn means the
> library could never migrate to testing.
>

In my experience, arch teams will always take the path of least
resistance. That path is rarely, if ever, the correct path for the
rest of the distro to take. If arch teams had their way, no system
libraries would ever be ported to Rust.

It's not that arch teams are lazy, they're just overworked and the
build machines are crappy and slow.

> The situation around rust has to improve first before we can consider that.
>

The situation *will not improve* till core packages start requiring
Rust which will force arch teams to deal with the situation instead of
postponing it forever. I suspect it will happen soon regardless of
what librsvg does, because Firefox is never going to stop requiring
Rust.

Actually, looking at the tier-2 support criteria[1], mips, sparc,
sparc64, s390, ppc, and ppc64 are guaranteed to build upstream and
they FTBFS in Debian, so something is off here.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series

[Nirbheek Chauhan]

On Sat, Dec 16, 2017 at 8:17 PM, Michael Biebl  wrote:
> Our porters, from what I know, tried to bootstrap rust on various
> architectures but run into multiple issues.
> A few of them you can see at
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rustc
>
> If you need more details, I can ask them. All I know that this
> situation is basically unchanged for a long time already.

I think this is something only arch teams can work on. I don't have
access to mips or s390 machines.

Having worked with arch teams in Gentoo, I understand that they're all
overworked and the work is slow because the machines have almost no
resources, but the work has to be done.

> Probably doesn't help that rustc considers anything non i386/amd64 as
> non-first tier supported.
>

This is a bit of a misunderstanding. What "tier-1 support" means is
that their full CI is run for all supported architectures and OSes for
every PR, and then that PR is merged on top of the tip and the CI is
is run on that again. It's a very comprehensive level of of testing,
and aiui it also includes performance regression testing and so on.
It's basically impossible to run CI on that scale for an organisation
like Rust for fringe arches like s390/mips/m68k/etc, so they cannot
advertise it.

However, I have talked to upstream Rust folks in person and they have
always said that they welcome patches to improve arch support, and
they would really like it if distros ran CI for them as often as they
can and report regressions early in the release cycle.

Effectively, we'd have the same situation with Rust that we have for
all other packages in existence, but with a more welcoming community
behind it. The problem is that of bootstrapping the process, and that
can only happen once packages actually requiring Rust.

I think Debian should start using librsvg 2.41 and arch teams should
just deal with that reality.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series

[Nirbheek Chauhan]

On Sat, Dec 16, 2017 at 7:18 PM, Michael Biebl  wrote:
> 2017-12-16 1:28 GMT+01:00 Federico Mena Quintero :
>> People are *STRONGLY* encouraged to switch to 2.41.x as soon as
>> possible.  Librsvg 2.41.x is ABI and API compatible with 2.40.x, so it
>> is a drop-in replacement.  You only need a Rust toolchain to compile
>> it.  If you or your distro can compile Firefox 57, you can probably
>> compile librsvg 2.41 without problems.
>
> We'd love to switch in Debian, but
>
> https://buildd.debian.org/status/package.php?p=rustc=unstable
>
> is effectively preventing us from doing that.
> Looks like Firefox 57 is not coming to stable Debian release either
> anytime soon:
> https://buildd.debian.org/status/package.php?p=firefox=sid
>

I am not sure I understand the status here. Are the failures because
of missing arch support in llvm or because the arch teams just haven't
gotten around to bootstrapping cargo and rust yet?

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.25.90 will probably be delayed

[Nirbheek Chauhan]

On Mon, Aug 14, 2017 at 3:48 AM,   wrote:
> Whew, it's done! I wound up doing a minimal number of workarounds:
>
> * Held colord at a previous version
> * Built PackageKit without Vala support
> * Built totem without plugin support
>
> This is a normal amount of workarounds. There's always a few hacks we need
> to do to get everything building. So in the end I'm pleased with the level
> of quality.
>
> Better late than never,
>

Thanks Michael (and everyone else!) for doing the hard work of
whipping everything into shape :)

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: developer.gnome.org and meson

[Nirbheek Chauhan]

On Fri, Aug 11, 2017 at 4:10 PM, Stefan Sauer <enso...@hora-obscura.de> wrote:
> On 08/09/2017 10:11 PM, Nirbheek Chauhan wrote:
> > Somewhat relatedly, the only reason why it takes so long to build docs
> > is because we haven't been improving gtk-doc. There is little
> > technical reason why building our documentation has to be *so* slow.
> > For instance, there's Hotdoc which as a proof-of-concept does the same
> > work, but much faster. So perhaps our time is better spent figuring
> > out why gtk-doc eats CPU (single-threaded!) and fixing that.
> It is not a secret why gtk-doc is slow. It is slow because libxslt and
> the xsl-stylesheets are slow. In particular libxslt is single threaded.

Thanks for the clarification, Stefan :)

> In the gtk-doc-1.26 I just release, everything was ported to python.

Yes, I was following the port to Python. It was great! Another step
towards getting rid of Perl from our toolchain. I have a vested
interest in this because it makes bootstrapping builds on, for
example, Windows much easier.

> Next step is to remove file generating code from the xslt pipeline. Then
> we can replace xslt by e.g. a markdown toolchain. I appreciate what was
> done in hotdoc, but I'd like to provide a step by step migration path
> for existing modules. I never understood why what has been done could
> not have been made inside gtk-doc as well.
> I appreciate anyone helping (like jussi helping a lot with porting from
> perl to python).
>

I completely agree, my mention of Hotdoc wasn't an endorsement of it,
but rather to say that there is room for improvement in the time it
takes to build our docs. A gradual migration to a markdown-based
toolchain would do wonders. Do you have any bugs about the work that's
needed so people can dive in if they can?

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: developer.gnome.org and meson

[Nirbheek Chauhan]

On Thu, Aug 10, 2017 at 1:27 AM, Sébastien Wilmet  wrote:
> On Wed, Aug 09, 2017 at 03:20:38PM +0100, Emmanuele Bassi wrote:
>> After all, Linux
>> distributions rebuild the documentation when building the binary
>> packages anyway
>
> I see that in the gspell-doc package on Fedora 26, some html pages have
> links to /home/seb/jhbuild/... (a problem with the gtkdoc-fixxref
> config). That's my home directory :-) so definitely Fedora didn't
> re-generate the docs (and it would be painfully slow, it takes several
> hours on my machine to generate the GTK+ docs).
>

Somewhat relatedly, the only reason why it takes so long to build docs
is because we haven't been improving gtk-doc. There is little
technical reason why building our documentation has to be *so* slow.
For instance, there's Hotdoc which as a proof-of-concept does the same
work, but much faster. So perhaps our time is better spent figuring
out why gtk-doc eats CPU (single-threaded!) and fixing that.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Nirbheek Chauhan]

On Wed, May 17, 2017 at 3:15 PM, Bastien Nocera  wrote:
> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>>
> 
>> Most developers are more familiar with the GitHub workflow, I think
>> it's
>> an easier workflow than attaching a patch to a bugtracker ticket.
>> Once
>> the contributor has pushed a branch on the fork repo, all the rest
>> can
>> be done from the web interface by clicking on some buttons.
>
> I absolutely hate this workflow, fwiw. I prefer being able to run "git-
> bz" to both create and apply patches, rather than keeping a clone with
> a bunch of patches in my own org, or remembering the commands to push a
> repo to my own repo from the upstream clone.
>
> I hope there will be a git-bz equivalent available.

I would love a git-bz equivalent for this so I can use it for the
projects I contribute to on GitHub ;)

This reminds me, does GitLab allow you to review the commit message of
a patch or series of patches or does it hide it away like GitHub does?
I often forget to review the syntax and content of the commit message
because of this on GitHub, and this is probably quite important for
GNOME projects.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitHub Development Platform for GNOME

[Nirbheek Chauhan]

On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  wrote:
> I want to share my humble opinion and thoughts about GitHub/GitLab:
>

>From what I've been hearing, people within GNOME have been evaluating
the possibility of running our own GitLab instance, so I would wait
and see what the results of their testing is.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Equivalent of recursive make with meson/ninja?

[Nirbheek Chauhan]

On 11-Feb-2017 18:32, "Sébastien Wilmet"  wrote:

> and it will only recompile/relink the bits that have changed, and
> nothing else. It will be very very fast in most cases.

It'll also relink all the tests and rebuild the docs (GTK-Doc is very
slow).


Fwiw, it won't rebuild the docs since that is done at install time, not at
compile time. It also won't relink all the tests if you specify a target
(an executable, library, etc) to build. You can also rebuild a specific
file by specifying the corresponding .o file, and I'm sure that can be made
more convenient with a wrapper tool.

I think your use-case can even be improved by writing such a tool that will
rebuild only a specific file. This would actually be faster than make even
because it wouldn't relink anything in that directory unless you want it
to.

Would you like to take a shot at it? It's really simpler than it might
seem. Just a matter of reading the compiler db (json file) and calling
ninja with the right argument. :)

IMO this is one of the major advantages of Meson. It actually provides an
API that you can use to support and even improve your custom workflows.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

[Nirbheek Chauhan]

On Fri, Jan 6, 2017 at 6:59 AM, Federico Mena Quintero
 wrote:
> On Thu, 2017-01-05 at 20:21 +0100, Michael Biebl wrote:
>>
>> It has been mentioned on #debian-devel that rustc is really only
>> supported on i386 and amd64 (as a so-called tier1 architecture).
>> https://buildd.debian.org/status/package.php?p=rustc=sid looks
>> pretty sad.
>>
>> Just curious if you aware of this limited portability?
>>
>
> Yes, and I don't lose sleep over it :)
>
> A couple of years ago people were screaming that GNOME didn't build on
> S390.  Some distro picked up the work and now things are fine.  I
> expect them to do the same for Rust.
>

Speaking of s390, it looks like there's people on the Rust end that
are using it and working on it too :)

https://twitter.com/gwesfisher/status/817175453559570433
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nirbheek Chauhan]

Hello,

On Thu, Oct 13, 2016 at 4:23 PM, Sam Thursfield <sss...@gmail.com> wrote:
> I agree with the sentiments above that Meson isn't quite ready for this
> yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
> both cases there have been several patches needed to Meson, some of
> which are still unfinished.
>
> Many people other people seem to be trying out Meson already, which is
> good, and suggests we don't need to do anything further right now to
> encourage people to try it out.
>

Yes, the GNOME module in Meson has had several improvements merged,
and more in the pipeline. Thanks for your patches!

We've been hard at work to make everything work smoothly for GNOME
projects, and have had a lot of interest; particularly from the Vala
folks. It's quite encouraging! Our goal is to have GNOME and Vala
support working flawlessly out of the box ASAP, and people coming and
telling us what they need has been a great help in that regard.

If you are thinking about trying Meson out and need help, hop on to
#mesonbuild on Freenode and find us. :-)

PS: We'd really like some help in making our documentation more newbie
friendly too.

> There are GStreamer build instructions using Meson at
> <https://github.com/centricular/gstreamer/> (and /gst-plugins-*/) which
> seem pretty complete and I believe they're already being used to
> cross-compile GStreamer to Windows.
>

Just bunch of small corrections. The GStreamer Meson build files have
been merged upstream (alongside Autotools), so it is recommended that
you get them from there:

https://cgit.freedesktop.org/gstreamer/gstreamer/

+ /gst-plugins-{base,good,bad,ugly}, etc.

We also have a git repo that uses Meson's subproject feature to build
gstreamer + plugins in one tree in one go:
https://github.com/thiblahute/gst-all . This is the recommended way of
building GStreamer with Meson on Linux using the system-install
dependencies.

We have our own "jhbuild/continuous-equivalent" called Cerbero that is
used for building GStreamer in other configurations. The default build
used there is still Autotools. For that, we have a branch
(https://github.com/centricular/cerbero) that can build gstreamer +
plugins on Linux, on native Windows, and can cross-compile to Windows
on Linux.

> For GTK+, there are preliminary build instructions for GTK+ at
> <https://bugzilla.gnome.org/show_bug.cgi?id=769881>. I guess it would be
> a few days work to make these nearly-complete. So I think Meson is close
> to being able to pass that test already.
>

There's also a Glib repository with Meson build files
(https://github.com/centricular/glib), but just like the GTK+ build
it's not complete yet, and we're working on making it have
feature-parity with the Autotools build and the Visual Studio project
files shipped with the project. It's just a matter of going over the
Autotools build files line by line and checking that everything has
been translated over.

Cheers,

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Tool to rename a GObject written in C?

[Nirbheek Chauhan]

Hi Sébastien,

On Thu, Sep 10, 2015 at 10:52 PM, Sébastien Wilmet <swil...@gnome.org> wrote:
> Renaming a GObject written in C can be done with some sed substitutions,
> but after that the indentation is broken.
>
> Do you know a tool to rename a GObject while still keeping a good
> indentation and coding style?
>

A few years ago, LWN did some coverage of a semantic
patching/indentation project for C called Coccinelle:

http://coccinelle.lip6.fr/documentation.php
https://lwn.net/Articles/315686/
https://lwn.net/Articles/380835/

I think this does exactly what you are looking for (and more).

Cheers,
Nirbheek

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new maintainer for gnome-dictionary?

[Nirbheek Chauhan]

On Mon, Oct 6, 2014 at 8:42 PM, Emmanuele Bassi eba...@gmail.com wrote:
 anybody looking for an *actual* dictionary. any and all replacements
 are actually worse, and the only half-decent, maintained, and free (as
 in beer) dictionary source we can use is Wiktionary, for which we
 could simply ship an epiphany-based Web app anyway.


If anyone wants to work on a replacement dictionary UI, I'd vote for
something similar to spotlight integrated into GNOME Shell or
spell-integration in GTK+ rather than a separate app. The dictionary
integration in the Kindle, iOS, and OS X is much more useful than a
discrete app (saves a context switch, less effort, etc).

I do agree that Wiktionary is probably the best source we have. A tiny
library wrapper would suffice to make it available to applications!

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new maintainer for gnome-dictionary?

[Nirbheek Chauhan]

On Mon, Oct 6, 2014 at 9:36 PM, Emmanuele Bassi eba...@gmail.com wrote:
 I think we should have some integration at a platform level — i.e.
 dictionary as a service — that apps and the shell can use to show
 word definitions.

 I *definitely* don't think we should integrate this stuff in the shell
 as a default; the shell is not the kitchen sink, and it cannot display
 large quantities of text.

 an app can provide a shell search provider fairly easily, and it can
 expose a DBus API that shows a bubble at given coordinates with the
 text definition for those apps opting in.


Sure, I didn't mean that the Shell has to contain all the logic
necessary for a dictionary app, I meant that we need better
mechanisms/widgets for displaying such content than we currently have.
For instance, the search provider is not the best place to show a
dictionary definition because it's a context-switch (you can't see the
original text while looking that up). I think this problem also exists
for the new calculator support added to the shell. Right now, it's
easier to use the Firefox search bar for calculations since it shows
you the result in a drop-down list.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Combined system status updates

[Nirbheek Chauhan]

These look rather nice. My only concern with these wireframes is that
they would make the menu far too long. Would this menu still fit on
1366x768 or 1024x600 screens in landscape mode?

On Mon, May 13, 2013 at 4:32 PM, Allan Day allanp...@gmail.com wrote:
 Hi all,

 Me, Jon and Jakub have reviewed the combined system status designs in
 the attempt to address the feedback that we've got. A fresh round of
 wireframes are now on the wiki [1]. I think that they resolve the most
 serious issues that have been raised.

 Allan

 [1] 
 https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus#Update_Proposal

 --
 IRC:  aday on irc.gnome.org
 Blog: http://afaikblog.wordpress.com/
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Combined system status updates

[Nirbheek Chauhan]

On Tue, May 14, 2013 at 12:41 AM, Rovanion Luckey
rovanion.luc...@gmail.com wrote:
 2013/5/13 Nirbheek Chauhan nirbh...@gentoo.org
 These look rather nice. My only concern with these wireframes is that
 they would make the menu far too long. Would this menu still fit on
 1366x768 or 1024x600 screens in landscape mode?

 On my 1366x768 it's often that the whole wireless menu doesn't fit when
 expanded as it is now. It is worth to keep in mind.

That is unavoidable and can happen at any resolution since we can't
control how many WiFi APs are being broadcasted. However, we *can*
control what an ordinary menu size is in this case.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Combined system status updates

[Nirbheek Chauhan]

On Tue, May 14, 2013 at 12:50 AM, Andreas Nilsson li...@andreasn.se wrote:
 On 2013-05-13 16:02, Nirbheek Chauhan wrote:
 These look rather nice. My only concern with these wireframes is that
 they would make the menu far too long. Would this menu still fit on
 1366x768 or 1024x600 screens in landscape mode?

 I too was a bit shocked to see the All Possible System Menu, but realized
 it's a very extreme case.
 Usually a menu would be top ~10 items.


I beg to differ there! On my laptop with its default setup, I would
see 13 items + 5 separators on the menu at all times (increasing to 14
with updates).

Do we have a mechanism for scrolling (or its equivalent) when the
menu length exceeds the screen height? How would this interact with
scroll bars inside sub-menus? Is such a mechanism desirable?

It seems to me that these problems are unavoidable with a single
consolidated menu.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Combined system status updates

[Nirbheek Chauhan]

On Tue, May 14, 2013 at 1:25 AM, Allan Day allanp...@gmail.com wrote:
 Nirbheek Chauhan nirbh...@gentoo.org wrote:
 If anyone is interested in this, check out the examples [1]. On a
 laptop with a single user account and VPN, I count eight menu items,
 for example.

 I beg to differ there! On my laptop with its default setup, I would
 see 13 items + 5 separators on the menu at all times (increasing to 14
 with updates).

 Can you explain how you came up with those numbers? Do you have
 multiple VPNs/Mobile Broadband connections? I'm not sure that 5
 separators will even be possible...


I miscounted the separators, sorry about that! 4 is the correct
number. My network bits look like this:

* WiFi (displayed if device is capable)
* Mobile Broadband (USB 3G dongle, connected)
* VPN1 (Work VPN)
* Bluetooth (Switched on at boot)

And I have a Guest user on my system for people who want to use my
machine, so that adds the Switch user and Logout options. That
makes it 13, by my count—unless I've misunderstood something about the
menu? This isn't the average case, but it's not an atypical case
either.

FWIW, I know it's a bad idea for non-designers to give design
suggestions, but it seems to me that splitting the network menu might
be a nice thing to do.

 Do we have a mechanism for scrolling (or its equivalent) when the
 menu length exceeds the screen height? How would this interact with
 scroll bars inside sub-menus? Is such a mechanism desirable?

 GTK+ menus can certainly scroll when they reach the limit of the
 available space. I'm not sure about St ones, but that should be
 possible. That said, scrolling a menu isn't a great thing and I'd like
 to think that we can avoid it. According to my rough calculations, a
 menu with 13 items in it (which would be pretty rare) would be about
 550px tall.


I'm glad you agree that scrolling the menu should be avoided! It's bad
for both touch screens and mouse pointers. I would also posit that a
large menu is hard to navigate using a mouse pointer.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Prototyping navigation in Epiphany

[Nirbheek Chauhan]

On Fri, Jun 8, 2012 at 10:45 AM, Bastien Nocera had...@hadess.net wrote:
 On Wed, 2012-06-06 at 16:30 -0400, Jeremy Bicha wrote:
 As has been said many times on this list, unlogged IRC is not an
 adequate collaboration solution for a large international open source
 project like GNOME.

 Except it's high-bandwidth, and with a quicker turn-around. That's also
 been said many times.


I think Jeremy just means that we should log conversations and have
them available in some manner.


-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: Totem - Videos

[Nirbheek Chauhan]

On Tue, Apr 24, 2012 at 8:03 AM, Alberto Ruiz ar...@gnome.org wrote:

 If you ask me, I think torrents should be integrated in the browser, no
 other browser implements this and would make the torrent downloading
 experience much more transparent to the user.


No other browser, except… Opera? :)



-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

[Nirbheek Chauhan]

On Fri, Jan 20, 2012 at 10:49 PM, Emmanuele Bassi eba...@gmail.com wrote:
 On 20 January 2012 17:12, Michael Biebl mbi...@gmail.com wrote:
 It's unfortunately not as simple as that as far as Debian is concerned
 or any other non-Linux distro. systemd is Linux-only. The
 aforementioned components timedated, hostnamed and localed can't be
 compiled on non-Linux systems.

 this hasn't changed: non-Linux systems were not supported before
 either. actually using, by a neutral DBus interface instead of ad hoc
 code for each platform, it may be easier to get support on other
 platforms without requiring to patch g-c-c directly.


For those finding it hard to understand how this is better than before:

Try to think of it as a freedesktop standard for time and date (like
org.fdo.Notifications). It even uses the same DBus namespace! Once a
provider is implemented (by porting timedated or whatever) it can be
reused everywhere.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: multiple vala versions in 3.4

[Nirbheek Chauhan]

On Fri, Jan 20, 2012 at 3:02 AM, Colin Walters walt...@verbum.org wrote:
[snip]
 However, modules will need to be patched to find the correct valac and
 vapigen with the -0.14 suffix.  For example, folks just does:

        AC_PATH_PROG([VAPIGEN], [vapigen], [])
        if test x$VAPIGEN = x; then
              AC_MSG_ERROR([Vala must be built with --enable-vapigen])
        fi

 We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to
 configure, but it's probably better to fix this inside the configure
 scripts.


Just a small clarification here in case people end up trying this.
What needs to be passed is VALAC=$(which valac-0.14) VAPIGEN=$(which
vapigen-0.14), i.e. the full path to the binaries; since AC_PATH_PROG
doesn't read $PATH unless told to.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Nirbheek Chauhan]

On Tue, Sep 20, 2011 at 2:38 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Mon, Sep 19, 2011 at 11:05 PM, Ionut Biru io...@archlinux.ro wrote:
[snip]
 In my opinion this survey should be published after gnome 3.2 is presented
 to a larger audience, now that ubuntu 11.10 is going to have it, opensuse
 12.1

 That would be what? December? I think that's too far, perhaps for the
 2012 survey.


Why does the survey *have* to be done *right now* at all?

I thought the primary aim of this survey was to give useful feedback
which would be used to improve GNOME. The first step in evaluating
software is to use the latest version — there's no use asking people
for feedback about GNOME 3.0 when 3.2 is coming out in a week.

There's been a lot of work done to improve GNOME 3 over the last 6
months. A lot of the complaints of GNOME 3.0 have been already
addressed. Why not just do it after (even more!) distros ship GNOME
3.2?

Cheers,

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.1.90 beta released!

[Nirbheek Chauhan]

On Thu, Sep 1, 2011 at 10:55 PM, Evandro Giovanini
efgiovan...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 12:24 PM, Bastien Nocera had...@hadess.net wrote:
 See https://bugzilla.gnome.org/show_bug.cgi?id=657496

 I hope we get some hardware that's a bit more advanced than this 1990's
 behaviour in the future.



 As someone misfortunate enough to have used a WM phone for a few
 months I don't see what's so bad about the classic behaviour (for the
 lucky ones that may be unaware, I basically had to manually remove the
 battery every other week to recover from an OS crash).


On my laptop, I encounter enough hard lockups while testing software
that the long-press behaviour of the power button is essential for me.
I don't want to have to flip my machine over and take out the battery
everytime. For all I know, doing that repeatedly might even damage the
device.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.1.90 beta released!

[Nirbheek Chauhan]

On Fri, Sep 2, 2011 at 12:40 AM, Germán Póo-Caamaño g...@gnome.org wrote:
 On Fri, 2011-09-02 at 00:18 +0530, Nirbheek Chauhan wrote:
 On my laptop, I encounter enough hard lockups while testing software
 that the long-press behaviour of the power button is essential for me.
 I don't want to have to flip my machine over and take out the battery
 everytime. For all I know, doing that repeatedly might even damage the
 device.

 In the worst case, you still can use the Magic SysRq key.
 http://en.wikipedia.org/wiki/Magic_SysRq_key


They often don't work in case of kernel lockups, or Xorg problems
(which often lockup the kernel). They've worked maybe half the time
I've had a system lockup.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.2: gjs/seed

[Nirbheek Chauhan]

Just a small correction here.

On Thu, Apr 21, 2011 at 2:08 PM, Maciej Piechotka uzytkown...@gmail.com wrote:
 7) Embedding Mozilla engine stopped being supported.


https://lwn.net/Articles/436440/
https://lwn.net/Articles/436461/

= mozjs embedding is still supported

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 3

[Nirbheek Chauhan]

On Sun, Apr 17, 2011 at 3:41 AM, Josselin Mouette j...@debian.org wrote:
 Le jeudi 14 avril 2011 à 05:17 -0400, Jasper St. Pierre a écrit :
 Other people want it because suspend doesn't work on their hardware.
 Adding a configuration option is just putting wallpaper over the
 cracked wall; the real solution is to fix suspend.

 I’m sorry but I don’t buy this. Suspend is among the things that have
 always been broken, mostly because of broken BIOSes. As long as we don’t
 have control over the hardware, we can’t be sure it works.


You're absolutely right. This is precisely the reason why Apple is
able to ship quality OSes that boot fast, work as expected, and give
excellent performance (iOS and OS X). OTOH, my own machine has a
partially-working suspend because the media keys stop working on
resume[1].

This is why I think GNOME should start a marketing campaign of
Awesome Hardware which is known to work flawlessly, and Sadface
Hardware which is known to work, but with glitches. This can help
users make informed choices while buying machines (or building them),
and would help us improve hardware support for Linux as well. In most
cases, it's just the last 1% that's left.

This is quite similar to the wireless hardware whitelists/blacklists
that we've been using for a while.

 And in the meantime, the wallpaper should be to detect suspend works
 as intended, and do something else if you can't.

 How can it detect that? There are just way too many ways it can fail.
 Some machines will suspend but never resume. Some will resume but in a
 wrong state. At that moment it’s too late to detect that suspend doesn’t
 work. (And if you are talking about a whitelist/blacklist, then think of
 its maintenance too.)

 Even worse than the “suspend on lid close” behavior, is the idea to
 suspend instead of shutting down. Computers are not all laptops, some of
 them require to be unplugged sometimes. Laptops are not all used
 everyday; they do not last more than 2 days in suspend mode.

I honestly think that the solution to this problem is suspend-hybrid
support[2]. Write hibernate image to swap, then turn off disk and
suspend to ram. That way if you pull the plug or the laptop battery
dies, the machine just resumes on boot, and you don't lost any of your
work. This is precisely what Apple already does.

 Add to that
 the need to reboot to install kernel updates.


I think this would be handled via PackageKit integration — you get
prompted to reboot/relogin when an update is installed that needs such
a thing.

 You need to take into account that the vast majority of our users use
 PC-class hardware. And you might not like it, but with such hardware
 they need to learn the difference between reboot, shutdown and suspend.
 It’s true that it should not be the case, but if you want to fix that
 you should develop hardware, not software.

As I said above, if we get suspend-hybrid support added to the kernel,
computers that run directly off AC mains are covered as well.

Cheers,

1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657338
2. https://bugzilla.gnome.org/show_bug.cgi?id=560085

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: SoC idea: desktop file cache

[Nirbheek Chauhan]

Hey everyone,

On Sat, Mar 26, 2011 at 12:25 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Colin Walters [2011-03-25 12:18 +0100]:
 == Desktop File Cache ==
 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.
[snip]
 I played aorund with various file formats, and actually
 found that with gnome-menus a simple GKeyFile actually worked best,
 since in the end we want to read all the relevant desktop files
 anyway, and reading them linearly out of the file cache into the
 internal DesktopEntry tree representation was fine.
[snip]
 The next question is how does the cache get rebuilt?

[snip]
 So we went for the pragmatic solution and only do caches for
 /usr/share/applications. (The patch above works with any desktop
 directory, but we only build cache files for that one). We have a
 script [3] to build the cache, which gets run by the package manager
 whenever a package adds/changes/removes/modifies files in
 /usr/share/applications/. (In dpkg terms this is called a trigger).
 So we only have some extra overhead at package install/upgrade time
 (which is already slow enough, so that the extra second doesn't
 matter), but no extra overhead at runtime.

 This concept is very hard to generalize as an upstream solution, of
 course. The gnome-menus patch [2] and the script [3] aren't distro
 specific at all, but the concept of package triggers simply doesn't
 exist with upstream tarballs, and thus there will always be some
 distro specific integration here.

 Also, I'm well aware of the corner case that this would simply ignore
 desktop files that the admin puts into /usr/share/applications/. We
 currently treat this case as don't do that then, that's what
 /usr/local/ is for, but it's of course a small design wart of this.


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?

Of course, we'd have to come up with a format for that, but I think
the GKeyFile format that the Ubuntu folks have come up with could be
reused since the mimeinfo cache is a GKeyFile as well.

As I understand it, this would be equivalent to the Ubuntu solution,
would be applicable as an upstream solution, and would be useful for
other DEs as well. Since we have the time, this should be very doable
in time for 3.2.

Cheers,

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some more problem modules

[Nirbheek Chauhan]

On Tue, Feb 8, 2011 at 6:31 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Picking up the ball again on problematic modules...

[snip]

 Unfortunately, there is a number of other modules that lack attention,
 have not had commits in a while and/or don't build for a long time in
 build.gnome.org:

 - vino
 - vinagre
 - seahorse-plugins

 Lets get these into shape for GNOME3.


For the record, below are the relevant GNOME3-related bugs for these
three packages. I didn't list any critical bugs with the apps
themselves since I cannot judge those.

vino:
Adapt to GTK+3 Rendering Cleanup --
https://bugzilla.gnome.org/show_bug.cgi?id=631670
port to libnotify 0.6.1 --
https://bugzilla.gnome.org/show_bug.cgi?id=631949 (trivial patch)
Migrate from dbus-glib to glib's GDBus --
https://bugzilla.gnome.org/show_bug.cgi?id=622879 (not essential)

vinagre:
don't use gdk_draw_ in vinagre panel applet --
https://bugzilla.gnome.org/show_bug.cgi?id=629416 (also doesn't fit
into Shell)
Port to GSettings --
https://bugzilla.gnome.org/show_bug.cgi?id=625895 (not essential?)
Migrate from dbus-glib to glib's GDBus --
https://bugzilla.gnome.org/show_bug.cgi?id=622894 (not essential)

seahorse-plugins:
Port to latest gtk+3 (2.99.2) --
https://bugzilla.gnome.org/show_bug.cgi?id=639493 (trivial patch)
seahorse-plugins doesn't build with libnotify 0.7 --
https://bugzilla.gnome.org/show_bug.cgi?id=632800 (trivial patch)
Seahorse applet doesn't work with curent gnome-panel --
https://bugzilla.gnome.org/show_bug.cgi?id=641275
drop status icon use -- https://bugzilla.gnome.org/show_bug.cgi?id=633424
Migrate from dbus-glib to glib's GDBus --
https://bugzilla.gnome.org/show_bug.cgi?id=622886 (not essential)

This buglist is very incomplete since most people haven't been able to
actually build these and test them against gtk+:3

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IRC channels in gnome development

[Nirbheek Chauhan]

On Tue, Feb 8, 2011 at 12:22 AM, Andre Klapper ak...@gmx.net wrote:
 On Sun, 2011-02-06 at 19:19 +0530, Nirbheek Chauhan wrote:
 Is there a place where IRC logs of discussions from the various
 channels can be found?

 I am not aware of any automated GimpNet IRC channel logging and
 publishing.


It would be very useful to have a bot around which logs conversations
on #gnome-{shell,design,os} et al and puts it up somewhere. A number
of GNOME channels already have bots to manage chanops, those could
probably be put to this use as well, if possible.

To cover the conversations that have already happened; maybe people
can put up their logs of these channels of the past year (or whatever
they have). We can then patch up the various logs to make a full log.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IRC channels in gnome development

[Nirbheek Chauhan]

On Sun, Feb 6, 2011 at 7:16 PM, Andreas Nilsson nisses.m...@home.se wrote:
 On 02/05/2011 06:25 PM, Maciej Piechotka wrote:

 IRC channels seems to be used in gnome development. It may be just me
 but I believe that recent power setting crisis show (I contrast them
 to mailing lists):

  - Requires presence. Many people cannot afford being on irc 24/7 - both
 developers, potential developers or just interested users. The houres of
 the meeting may clash with working hours or other real live constraints.

 Yes, IRC has it drawbacks, but it also makes discussing design a lot faster
 and effective than doing it on mailing lists. We need to be time effective
 if we're going to make the April 6th release date.

Is there a place where IRC logs of discussions from the various
channels can be found?

Thanks,

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-panel gnome-applets?

[Nirbheek Chauhan]

On Fri, Dec 24, 2010 at 3:52 PM, Carlos Garcia Campos
carlo...@gnome.org wrote:
 Excerpts from William Jon McCann's message of vie dic 24 00:32:40 +0100 2010:
 GNOME 3 is a change.  Both the default and the fallback modes will be
 different from GNOME 2.  We can't and shouldn't shy away from that.

 I don't know if there are plans to work on gnome-panel for gnome 3,
 but in this moment the panel is exactly the same, or even worse since
 it doesn't even work with gtk3.


Is it a good idea to make gnome-panel work with gtk3? Will that break
all the gtk2 applets out there in the world which can't/won't be
ported?


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Minimum system requirements for GNOME Shell

[Nirbheek Chauhan]

Hello,

I was wondering what the minimum system requirements for running GNOME
Shell in a usable manner are/will be. I was only able to find vague
statements saying all computing devices in the last 4-5 years[1],
etc[2]. IMO, this ambiguity has led to a lot of uncertainty among
people about whether GNOME Shell will even launch on their machines.
It would be a good idea to publish a set of minimum and recommended
system requirements for GNOME Shell (similar to what is published by
games).

* Minimum OGL requirements to launch clutter
* Minimum Intel/ATI/nvidia chipset models with which a smooth
experience is guaranteed
* Minimum CPU configuration for software rendering mode under swrast
and llvmpipe (useful for VMs)

In addition to letting people know where they stand in all this, it
would also help *us* make sure that GNOME Shell is usable (60+fps with
no background processes, ~30fps with heavy background CPU usage) on
the systems that we target. If testing is currently being done only on
developer machines, we should begin to do testing on the minimum
hardware configuration that we intend to support.

I'm sure we all agree that a GNOME Shell which stutters, lags, and
drops to 15fps as soon as the user compiles something is not going to
be well-received.

Thanks!

1. 
http://live.gnome.org/GNOME3Myths#My_computer_and.2BAC8-or_graphics_card_isn.27t_powerful_enough_to_run_GNOME_3
2. 
http://live.gnome.org/GnomeShell/FAQ#What_led_to_the_decision_to_make_3D_acceleration_a_requirement_for_GNOME_Shell.3F

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Zeitgeist

[Nirbheek Chauhan]

On Sat, Apr 24, 2010 at 4:29 AM, Owen Taylor otay...@redhat.com wrote:
 On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote:
 I think Launchpad + BZR and GNOME + git can interoperate fine.
[snip]

 I think the question is, is this OK for a GNOME module?

 The main point of requiring use of GNOME infrastructure for GNOME
 modules, as I see it, is that anybody in the GNOME community can
 immediately jump in, start helping out, and start contributing to the
 module. And also, that people working on your module can seamlessly move
 over to working on other parts of GNOME. It's being part of the GNOME
 community.

[snip excellent points]
 However, the external dependency mechanism is really meant to be there
 for something that is already out there, that already has a stable
 version that we can depend upon and that provides the features we need,
 and that has a development community and process that are going to run
 independent of GNOME. It's not meant for something that is being
 cooperatively developed in tandem with GNOME features.


I was ambivalent to this discussion, but Owen has swayed me and I
completely agree with him now. I think this discussion has been trying
to follow the letter of the rules, but the intent has been forgotten.

One of the intents of the rules is to prevent fragmentation of
development, the codebase, and the community. Another is to allow
people (and distributors) to only need to follow one source of
information (the GNOME infrastructure) to work with upstream. This is
how GNOME's workflow is organised. If Zeitgeist goes outside this;
then it disrupts everyone's workflow whenever they need to interact
with Zeitgeist.

The external deps rule was added out of necessity; some projects are
more than just GNOME-centric; and belong on freedesktop, or a
completely/mostly DE/OS-agnostic infrastructure such as sourceforge,
github, code.google.com, launchpad, etc. We cannot say Python must
use GNOME infrastructure before python apps are allowed in the GNOME
stack; but we *can* say that for Vala because it was developed
specifically for use with the Glib/GNOME stack.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: GNOME Shell

[Nirbheek Chauhan]

On Sat, Apr 17, 2010 at 3:21 AM, Michael rasel...@hotmail.com wrote:
 * Moblin, which was also based on Clutter, worked without hardware
 acceleration (admittedly not particularly fast, but usable).

 * The visual effects in GNOME Shell don't look much beyond what Doom
 2 was doing on my completely unaccelerated 486 fifteen years ago,
 albeit with a lower resolution.  Furthermore, most of the time it is running
 with windows mapped one-to-one.  Surely an optimised path would be
 possible for this case?  I assume (am I wrong?) that that would be a
 Clutter issue, not a GNOME Shell one.  I think that with this fixed, I could
 happily live with slower, software rendered zooming windows (and I
 suspect that the Clutter folks would quickly find some way to make it
 work faster in software too).


This has been done in existing window managers too. See e17/e16
(enlightenment). All of it's effects are done in software, and run
smoothly on old hardware as well. However, that kind of thing took a
lot of dedicated effort on the part of the developers (doing this was
one of their primary aims). Doing the same in gnome-shell/mutter would
require massive re-orientation of goals; which I suppose is too late
to do now.

Such efforts *could* be directed in improving the software rasteriser
in Mesa; but that would probably require a lot of effort as well. Most
likely it's cheaper overall to just buy new hardware.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bump intltool version to 0.41.0

[Nirbheek Chauhan]

On Thu, Feb 25, 2010 at 1:10 AM, Luca Ferretti elle@libero.it wrote:
 Il giorno mer, 24/02/2010 alle 13.59 -0500, Rodney Dawes ha scritto:
 The canonical location for intltool tarball downloads is:
 https://launchpad.net/intltool/+download

 Fine, thanks. But if you no longer plan to use gnome.org for intltool
 tarballs, maybe someone should add a README file in that ftp directory
 saying new releases could be found on launchpad.


Or, just upload to both places. Surely it cannot be difficult to
automate it as a part of the upload-to-launchpad process. :)

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Packages with no changelogs

[Nirbheek Chauhan]

2009/9/26 Josselin Mouette j...@debian.org:
 It would be nice if maintainers could add changelog generation in all
 such modules – preferably one that doesn’t generate megabyte-large
 changelogs.


Thank you for bringing this up.

Automatically generating changelogs for release is trivial with
git[1]. ChangeLogs exist for a reason and the migration to git has
changed nothing in that respect. I'd like to hear coherent reasons
other than Oh, you can get it from git (which is the same as the
former excuse Oh, you can get it from svn)

1. http://live.gnome.org/Git/ChangeLog
-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Would this be a break?

[Nirbheek Chauhan]

On Sat, Sep 12, 2009 at 4:45 PM, Philippe Rouquier
rouquie...@wanadoo.fr wrote:
 I just got a patch today that add a minor feature to brasero (see
 https://bugzilla.gnome.org/show_bug.cgi?id=594954). Once applied the patch
 allow brasero to emit a sound. the code is quite small but I was wondering
 if it would be considered as a break for any of the freezes.

This won't break UI Freeze + String Freeze if there's no option in the
menu(s) to disable it (is it supposed to be there? Or is it supposed
to be globally controlled? Lennart should know this.)

We haven't hit Hard Code freeze though.

From the roadmap[1]: Sept 14: Hard Code Freeze: no source code
changes can be made without approval from the release-team.
Translation and documentation can continue. 

 My main concern
 is also that it adds a new dependency though libcanberra is part of the
 blessed external dependencies. What do you think?

I think the dependency problem is not too great if it's kept optional
via configure (--enable-sound ?)

1. http://live.gnome.org/TwoPointTwentyseven/

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: tracker

[Nirbheek Chauhan]

On Tue, Aug 18, 2009 at 6:30 PM, Patryk Zawadzkipat...@pld-linux.org wrote:
 On Tue, Aug 18, 2009 at 2:57 PM, Luis Medinaslmedi...@gnome.org wrote:
 On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:
    hal = 0.5
 Is there plans to replace HAL by GIO or devicekit ? Hal will be
 deprecated soon afaik.

 ...or rather by libgudev, there is no such thing as DeviceKit :)


I think he meant DeviceKit-{disks,power} (and any more to come) as
well. Not sure if Tracker would be happy with the existing gio+
DK-disks + DK-power, it may need more API added to each.


-- 
~Nirbheek Chauhan

GNOME Team, Gentoo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Menus restructuring

[Nirbheek Chauhan]

On Wed, Jul 29, 2009 at 1:19 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Tue, Jul 28, 2009 at 19:04, Matthias Clasenmatthias.cla...@gmail.com 
 wrote:
 I'd rather see us focus on moving away from these menus via
 gnome-shell and  and new control-center shell.

 And maybe remove as many settings as possible?


Is this a rhetorical question or a genuine question?

-- 
~Nirbheek Chauhan

GNOME Team, Gentoo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Menus restructuring

[Nirbheek Chauhan]

On Wed, Jul 29, 2009 at 1:34 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Tue, Jul 28, 2009 at 22:01, Nirbheek
 Chauhannirbheek.chau...@gmail.com wrote:
 On Wed, Jul 29, 2009 at 1:19 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Tue, Jul 28, 2009 at 19:04, Matthias Clasenmatthias.cla...@gmail.com 
 wrote:
 I'd rather see us focus on moving away from these menus via
 gnome-shell and  and new control-center shell.

 And maybe remove as many settings as possible?


 Is this a rhetorical question or a genuine question?

 100 percent genuine question. Not sure where you see the confusion,
 care to elaborate?


Rhetorical question in the sense that the way you phrased the
question, it seemed to me as though you were talking about the
perceived gnome habit of removing options at every chance.

Maybe I was just edgy from reading all the FUD about GNOME 3 I saw
everywhere I looked. :)

In the context of Sugar, do you see the GNOME shell becoming simple
enough for use as the Sugar Shell? Maybe that's why you asked the
question?

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Nirbheek Chauhan]

On Thu, Jul 23, 2009 at 12:10 AM, Jason D. Clintonm...@jasonclinton.com wrote:
 I am extremely grateful for all that Sun has done to move GNOME forward over
 the years--indeed much of that has benefited everyone including Linux. But,
 pardon me for pointing out the pink elephant in the room: why doesn't Sun
 just admit that (Open)Solaris is a dead-end?


a) Flamebait
b) Pointless since (Open)Solaris isn't the only non-linux platform.
*BSD are another large group.

Please, let's stay on-topic.

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list