Re: Proposal: Replace all references to master/slave in GNOME modules

[Richard Hughes via desktop-devel-list]

On Wed, 1 May 2019 at 12:38, Michael Gratton  wrote:
> They have also been successful in getting other projects to use more
> inclusive language. For example, MongoDB initially refused to stop
> using the term "master", but then relented after Python did so.

That's misrepresenting it *AGAIN*. Both stopped using master along
with slave. The main developer branch is still called master in both
projects.

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

Re: Proposal: Replace all references to master/slave in GNOME modules

[Richard Hughes via desktop-devel-list]

On Wed, 1 May 2019 at 06:23, Tristan Van Berkom via desktop-devel-list
 wrote:
> Proposing that we replace references to master/slave relationships with
> other terminology and proposing that we eliminate the usage of both
> words entirely are two entirely different proposals, this is a proposal
> of the latter which appears to be masquerading as the former.

This nails my thinking completely. I've already removed all references
to master/slave in my other projects (fwupd and LVFS), but renaming
the master branch which has no connection with any kind of slave is
just a completely different proposal.

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

Re: Proposal: Replace all references to master/slave in GNOME modules

[Richard Hughes via desktop-devel-list]

On Thu, 25 Apr 2019 at 06:21,  wrote:
> This should go without saying, but master branches are not a reference
> to slavery, rather to canonicity. The master branch is the canonical
> branch, the primary copy.

This is very much my thinking too. I'd agree with this proposal if
every branch forked from master was called slave/hughsie/whatever but
in this case the master is clearly referring to the canonical version
that the others are derived from. The word "master" isn't a bad word,
and doesn't always mean the opposite of slave.

I was hesitant to reply to this conversation as a middle-aged, middle
income white man but felt like I had to say something. I'll go get my
flame proof suit...

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

Re: App menu retirement: progress update

[Richard Hughes via desktop-devel-list]

On Wed, 31 Oct 2018 at 17:09, Allan Day  wrote:
> gnome-multi-writer

Removed in master.

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

GNOME Mastodon Instance?

[Richard Hughes via desktop-devel-list]

Hi all,

Now that Google+ is declared officially dead, I wondered if GNOME
would consider hosting a Mastodon instance. There's a bug already
open, https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/23
-- but I guess this needs someone to drive this and actually do the
work. I know I would trust a GNOME instance more than a random server,
both from a privacy point of view and security/moderation point of
view. It seems a shame to loose all the useful geeky connections with
people in the Open Source community, as people scatter to Twitter,
Facebook and all the other non-free places. Maybe now is the perfect
time to promote Mastodon and GNOME?

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

Re: No app menu changes for GNOME 3.30, please!

[Richard Hughes via desktop-devel-list]

On Tue, 24 Jul 2018 at 17:32,  wrote:
>  From the lack of objections to Allan's original proposal, it's clear
> that we have consensus on removing the app menus, so I suggest we
> should feel free to delete our app menus in master after branching for
> 3.30.

I'm currently on PTO for another week (stuck up a mountain with no
internet access) -- but I can certainly do this when I get back. There
are commits on top of the app-menu removal already so it's not just a
case of just reverting a patch.

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

Re: Meson feedback as a user

[Richard Hughes]

On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>  - Drop the "enable" from --enable-foo boolean options; Meson has
> boolean values, so -Denable-foo=true would read as redundant, and
> -Denable-foo=false would read as contradictory. Use -Dfoo=true or
> -Dfoo=false instead

I'm guilt of this, I'll fix up my projects, but before I do is there
any list of best practices? e.g. should it be

* -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
* -Dintrospection=true or -Dgobject_introspection=true?
* -Dman=true or -Dman_pages=true
* -Dconsolekit=false or -DConsoleKit=false

Thanks,

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

Re: Include GNOME Usage in the future releases

[Richard Hughes]

On 16 October 2017 at 19:17, Andreas Nilsson  wrote:
> .Power

If we put the power statistics here I can finally let gnome-power-manager die.

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

Re: Application name strings consistency

[Richard Hughes]

On 4 September 2017 at 14:13, Allan Day  wrote:
>> But names also need to sufficiently identify the named item. Ending up
>> with 5 "Clocks" and 4 "Maps" in gnome-software isn't really the best user
>> experience.
> I don't see that issue.

That's because I blacklist all the MATE and LXDE programs when running in GNOME.

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

Re: GitLab migration status and roadmap

[Richard Hughes]

On 14 August 2017 at 10:02, Jens Georg  wrote:
> I'm currently massively underwhelmed by the overall performance and
> snappiness of the web interface, even for a small project with not that
> much commit history.

Right; I also found that when sitting In London browsing
https://gitlab.gnome.org/GNOME/json-glib -- is the machine hosting the
GitLab instance a proper server in a datacenter somewhere or is the
demo being run from a test machine under someones desk? I don't want
people's first reaction to be "this is kinda slow".

Richard.
___
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

[Richard Hughes]

On 13 August 2017 at 15:35,   wrote:
> Now if I can get a new colord tarball, I think this might work.

I can do this tomorrow, today I have family things to sort today.
Thanks to everybody offering PRs for the colord issues, I've merged
all of them and I think we're in good shape now.

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

Re: Too many broken modules

[Richard Hughes]

On 31 July 2017 at 12:36, Arun Raghavan  wrote:
> Is there some place we can look at logs of the current build?

Same here, fwupd builds fine here, and also in Travis...

Richard
___
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

[Richard Hughes]

On 16 May 2017 at 15:23, Carlos Soriano  wrote:
> Glad to hear that. Could you mention what projects relevant for GNOME
> (either part of GNOME already or not) that you are maintainer of would
> benefit of a transition to GitLab?

Of immediate benefit would be gnome-software as we have lots of
different teams from lots of different companies all working together.
I'd ideally want the same workflow for my other projects, which would
probably include odrs-web, gnome-color-manager, gnome-packagekit, and
gnome-multi-writer.

Richard.
___
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

[Richard Hughes]

On 16 May 2017 at 14:22, Allan Day  wrote:
> The outcome of this evaluation process is that we are recommending that
> GNOME sets up its own GitLab instance, as a replacement for Bugzilla and
> cgit.

This is great news. Over the last few years I've started most of my
new projects on GitHub and then had to begrudgingly move them to
git.gnome.org for the translator teams and so that other people can do
drive-by fixes. GitLab would make this unnecessary and make it easier
for me to work with other people easily on reviews and PRs without all
the bugzilla spam. Certainly a huge +1 from me.

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

Re: For projects switching to Meson *only*

[Richard Hughes]

On 28 April 2017 at 01:00, Peter Hutterer  wrote:
> I will, but I'll keep the two parallel for at least a release or two.

I tried doing this in my projects last cycle and was a bit of a
disaster. Pretty much any committer that added files or changed how
the project was built, broke one of the two systems. Asking people to
test two quite different build systems before sending patches is
raising the bar a little too high and adding confusion. IMHO, etc.

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

Re: gnome-software and external plugins

[Richard Hughes]

On 22 May 2016 at 18:30, Michael Catanzaro  wrote:
> GNOME Shell extensions have this same problem. Firefox did better, but
> in the end it too had to give up; you've probably heard all its
> extensions need to be rewritten now.

Right; in one sense plugins let us prototype some new things easily
(that are headed upstream) and it also lets us support some of the
"enterprise" funk that big companies are asking us for in RHEL.
Compiling a plugin is a one line gcc command rather than building half
of GNOME in jhbuild which makes it easier to get started.

> It's not that external plugins in general are bad, it's that allowing
> them access to your application's internals is bad.

100% agree. To compile an out of tree plugin you have to define the
alarmingly-obnoxious-and-long
I_KNOW_THE_GNOME_SOFTWARE_API_IS_SUBJECT_TO_CHANGE and we really
restrict the API that plugins can use; I've been carefully splitting
out functionality into -private.h headers recently that plugins have
no business meddling with and I'm quite happy with the minimal API
surface I'm presenting so far. I guess my statement about out-of-tree
plugins being a bad idea in the introduction perhaps isn't strong
enough, I can certainly ramp up this if you think it would help. From
my point of view if I break your external plugin due to an API change
in the core you should have pushed your changes upstream sooner.

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

Re: Including content ratings in games

[Richard Hughes]

On 9 March 2016 at 18:30, Zbigniew Jędrzejewski-Szmek  wrote:
> So "Cartoon Violence" can be merged with "Fantasy Violence",

I don't think these are the same at all. If you look at the age
differences reported here
https://www.commonsensemedia.org/about-us/our-mission/about-our-ratings
you can see the different types of violence are treated differently.
You're probably right in that Fantasy isn't well defined, and we
should fix that.

> "Realistic depictions of bloodshed" and "Depictions of bloodshed and the 
> mutilation of body parts"
> can be replaced with "Depictions of bloodshed or mutilation of body parts".

I don't think mutilation can be equated with bloodshed. I always think
back to games like Doom where you see "splatter" but not much more.

> I think you can drop "Humor" totally, it's legal in most jurisdictions after 
> all.

I'm not really concentrating on the legality in a specific country,
more about suitability. I'm not sure I'd want my 3 year old repeating
profanity from a video game just yet.

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

Re: Including content ratings in games

[Richard Hughes]

On 9 March 2016 at 15:59, Simon McVittie  wrote:
> Here's an earlier attempt at the same thing, which if I remember
> correctly was led by Miriam Ruiz of the Debian games team:
> .

Useful, thanks.

> Debian publishes Appstream metadata now, so there's nothing that would
> stop us from publishing content ratings there.

Right, I'll contact Miriam and see if I can re-use/share some of the work there.

> This seems like something that doesn't need to be GNOME-specific, and
> indeed probably shouldn't be, particularly if you want random game
> upstreams to be adding this information.

Right, it's not GNOME-specific at all, but we'll be the one (again)
pushing the feature forwards first.

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

Including content ratings in games

[Richard Hughes]

Hi,

Sorry for the potentially off-topic posting. I've been working on a
new content rating system called OARS. I wrote up some notes on my
blog[1] but I've been asked to post to this list by multiple people.

The content rating system I'm going to be proposing has aspects of
privacy and has the potential to cause all kind of politics, and I
thought here might be a useful place to discuss this as gnome-software
should have the information for all games in GNOME 3.22. We've not yet
talked with the designers about how (or if...) this is going to be
shown in the GNOME Software UI. Unless some consensus is reached and
applications actually add the missing data there would be no point
doing anything any further.

I'm kinda hoping the people on this list might have a more balanced
view of child protection and privacy than the internet at large,
cough, reddit. It's probably also worth stating that I think this kind
of content rating should be informational-only, i.e. we're never going
to be stopping people installing applications.

I've uploaded my prototype generator here:
http://apps-xdgapp.rhcloud.com/oars and I'd appreciate any feedback on
that. Some of the categories may be difficult to translate or may need
further (or better) examples, and so any comments on or off-list are
very welcome. Also, don't actually add anything to AppData files yet,
as the categories are nowhere close to being finalised. Thanks!

Richard

[1] 
https://blogs.gnome.org/hughsie/2016/03/07/age-ratings-in-gnome-software-introducing-oars/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Richard Hughes]

On 28 February 2016 at 14:33, Emmanuele Bassi  wrote:
> What do maintainers think?

Makes sense to me. The quicker we catch a destdir/srcdir issue the
easier it is to fix.

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

Re: GNOME Software and fwupd

[Richard Hughes]

On 21 April 2015 at 10:33, Bastien Nocera had...@hadess.net wrote:
 It's a D-Bus service, can't it be a run-time dependency?

It could be, if we copy the fu-enums.[c|h] files.

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

GNOME Software and fwupd

[Richard Hughes]

I've just merged a patch to gnome-software which adds an optional (but
default enabled) dependency on fwupd[1]. The fwupd project just
provides a DBus interface for applying low-level firmware to various
types of devices.

I don't know if this makes sense for the continuous integration
server. I don't know if it makes sense to enable by default.
Installing firmware on more devices would be awesome (and make them
more secure) but it is Yet Another Dep.

Comments welcome,

Richard

[1] https://github.com/hughsie/fwupd
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME MultiWriter

[Richard Hughes]

On 9 January 2015 at 15:07, Olav Vitters o...@vitters.nl wrote:
 Could you make a homepage on the wiki like the other apps? It's not
 urgent, just nicer to have that to point to in the package.

Good catch, thanks. I've created the page and updated all the project
links: https://wiki.gnome.org/Apps/MultiWriter

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

GNOME AppData status page

[Richard Hughes]

Hi all,

I've uploaded a page with the AppStream metadata for Fedora 22 --
quite a few GNOME applications are missing easy-to-add things like
desktop keywords and some are missing HiDPI icons. It's awesome so
many GNOME apps are shipping AppData and I'm hugely grateful for that,
so we're really polishing things up now.

The page is here (warning 964k HTML page!), and is updated nightly:
https://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html

I'd appreciate it if you could have a look there and check your
application is green. If there are any false-positives or missing
applications then please let me know. I'm going to fix up the
applications I maintain now. Thanks!

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

Re: Applications in GNOME without AppData

[Richard Hughes]

On 13 October 2014 17:02, Daniel Mustieles García
daniel.mustie...@gmail.com wrote:
 If these are the only remaining modules to close the goal, the wiki page is
 really out-of-date.

Yes, it needs some review.

 Apart from these, all the red modules in the page have their corresponding
 Appdata file? It's ok to mark them as done, to avoid confussions?

If anyone wants to check a specific module you can use the Fedora 22
logs here: https://github.com/hughsie/createrepo_as_logs/

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

Applications in GNOME without AppData

[Richard Hughes]

Hi all,

Lots of GNOME applications now ship AppData files (95.6%!), and huge
thanks to everyone that's written or shipped one already. We do have a
few GNOME modules we possibly care about with no upstream attention.
These include:

* accerciser [1]
* gnome-screenshot [2]
* gconf-editor [3]
* xchat-gnome [4]

Is anyone interested in writing and/or committing a file upstream and
taking some screenshots? For some modules it means branching for 3-14
as it would mean adding new strings. It would be great to be the first
desktop with 100% AppData coverage. Thanks!

Richard

[1] https://bugzilla.gnome.org/show_bug.cgi?id=730872
[2] https://bugzilla.gnome.org/show_bug.cgi?id=736859
[3] https://bugzilla.gnome.org/show_bug.cgi?id=738385
[4] https://bugzilla.gnome.org/show_bug.cgi?id=730696
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Goals

[Richard Hughes]

On 24 September 2014 09:31, Martyn Russell mar...@lanedo.com wrote:
 I took a look at the GNOME goals just to see where Tracker was with
 them, we're actually implementing most of the new unproposed goals
 already and I had no idea.

Much the same as my modules; the burden of keeping the wiki up to date
is kinda high. It would be great if we could auto-generate the GNOME
goal status table so that it stays up to date.

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

Re: Gnome.org's crypto infrastructure

[Richard Hughes]

On 8 July 2014 13:24, Ray Strode halfl...@gmail.com wrote:
 1) tarballs would be generated with a standardized set of autotools,
 instead of whatever the maintainer happens to have installed

I think the opposite is true as well, in that some software needs
other frameworks in place to do distcheck rather than check -- for
instance colord needs a running colord daemon to test against. Other
software needs X.

Workaroundable, and I totally think something better than scp'ing
tarballs would be good.

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

Re: Icon theme changes

[Richard Hughes]

On 26 April 2014 15:04, Matthias Clasen matthias.cla...@gmail.com wrote:
 This will affect both jhbuild modulesets and distro packages

Just for 3.13.x, right?

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

Re: gnome-software/packagekit support for arch linux

[Richard Hughes]

On 27 March 2014 02:46, Sriram Ramkrishna s...@ramkrishna.me wrote:
 Unfortunately, none of them will be able to enjoy GNOME Software, due
 to the fact that there is no active development of a pacman backend
 for packagekit.  Arch Linux users are missing out on a major part of
 the GNOME eco-system.

There are two problem here. One is that indeed, the PackageKit arch
backend is under-maintained, and doesn't support the newer features
that gnome-software uses so heavily (e.g. the new filter enums). The
second is that arch does not generate AppStream metadata, so even if
the PackageKit backend worked well enough, there would be no rich
content (long translated descriptions, screenshots, ratings, etc) to
show. If anyone from arch wants to make this work, please grab me on
#PackageKit on freenode and we can talk in more detail.

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

Re: missing tarballs

[Richard Hughes]

On 25 March 2014 13:31, Giovanni Campagna scampa.giova...@gmail.com wrote:
 There are no commits since .92, is a release needed?

Please.

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

Re: gnome-settings-daemon wayland

[Richard Hughes]

On 13 February 2014 19:40, Rui Tiago Cação Matos tiagoma...@gmail.com wrote:
 while others might just need small fixes like the color or xrandr
 plugins.

The color plugin works well now (tested!), and the xrandr plugin
worked okay when I tested it about 3 months ago.

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

Re: UI Freeze Blockers

[Richard Hughes]

On 14 February 2014 10:43, Allan Day allanp...@gmail.com wrote:
  * 720946 gnome-control-center: Details panel - 'Install Updates'
 button is not working
  * 723760 gnome-software: Automatic star ratings [there's a
 contingency plan in here too]
  * 710109 gnome-software: Nicer standalone package installation

These three are mine I guess. I'll get hacking today.

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

Re: libgsystem as a shared library

[Richard Hughes]

On 5 February 2014 09:23, Colin Walters walt...@verbum.org wrote:
 My libgsystem ( https://wiki.gnome.org/Projects/LibGSystem ) library is now
 copied into sufficient number of modules that I'm considering making it a
 real shared library.

Cool, I've never really been a fan of submodules, and I'm much more
likely to use it in my projects as a shared library. One little point
tho, how come this can't be installed into GLib proper? I know it's
Unix only, but we've got plenty of other API that's unix specific in
the -unix.h headers. Less shared libraries better, etc.

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

Re: libgsystem as a shared library

[Richard Hughes]

On 5 February 2014 11:52, Colin Walters walt...@verbum.org wrote:
 GSConsole
 gsystem-log.h (systemd journal via a GLib-like API, also acts as a soft
 dependency)

Yes, that sounds awesome, but if libgsystem is going to be an egg
replacement I would say it's better to just copy and paste the source
files into modules; having an external library indicates some kind of
API and ABI promises, and you don't want to be proxying stuff in glib
for the next decade.

 Second, it contains backported API.  An example of this is GSSubprocess,
 which is now in GLib.  But a lot of my code (and NetworkManager) has to run
 on EL7 for example, which is just GLib 2.36. So it makes sense to have a
 common backport area.

As a shared library I'm not sure this argument holds, as a git
submodule it makes a lot of sense. I think putting stuff like this in
glib and surrounding them with I_KNOW_THIS_API_IS_UNSTABLE guards for
an unstable cycle makes a lot of sense while the API is still being
worked on and the early adopters are willing to release tarballs at a
moments notice.

 Third, it will contain APIs like the local allocation macros that I don't
 think should go into GLib.  (Although this is admittedly debatable)

I think they would be awesome in glib itself, and certainly would
encourage developers to start using them.

Richard.
___
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

[Richard Hughes]

On 29 January 2014 09:55, Daniel Mustieles García
daniel.mustie...@gmail.com wrote:
 gnome-control-center
 gnome-desktop
 gnome-software

Fine with me, thanks.

Richard
___
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

[Richard Hughes]

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

3.12 feature: GNOME Software

[Richard Hughes]

Matthias started with a mail about Wayland, it seems a good idea to do
the same for GNOME Software:

In 3.10,

 - We have a technical preview that includes desktop categories,
featured applications, and long descriptions for some apps. Installing
and removing are performed using the system PackageKit instance and
updates are performed using offline updates where available. To say so
myself it's impressive this much works after working on it for just a
couple of months, but a lot is still pretty hacky.

- Most of the time, gnome-software starts quickly, but sometimes
taking 10+ seconds on some PackageKit backends

- On some distributions, we have basic fonts previews in the addon category

- On some distributions, we have input methods in the addon category

For 3.12,

- We need to start the application in *all* circumstances in less than
1 second. No flicker, no loading bar.

- All GNOME modules need to have validated AppData[1] so we can show a
consistent details page for all core applications

- We need ratings, comments and screenshots in all GNOME (and
non-GNOME important applications, e.g. GIMP, Inkscape, etc).

- We probably need better categories than the menu-spec gives us.

- We need to properly work on the shared AppStream specification for
fonts and input methods so we can share this between distributions.

- We need to do something more sane about fonts, something like the
new mockup[2]

- We need to support packaging systems like Glick and Listaller so we
can install test applications per-user.

- We want to centralize all the update parts, possibly in a split
app/daemon model which Matthias has been playing with.

- We want to show Firefox webapps and things in the Chrome store.
Epiphany web applications are in the same category too. If you're an
expert here, we'd love some help.

- We need to start thinking about allowing donations for applications,
be it a centralised model where everyone gives to gnome.org, or a
decentralised model where random developers get money from PayPal or
bitcoins from random people.

If you're interested on working on any of these bits, please either
grab me on IRC (hughsie) or file a bug in bugzilla with details of
what you want to work on. Bugzilla [3] already has quite a few open
bugs about missing functionality, so feel free to pile on there with
ideas.

And for all those who've already committed validated translated
AppData files for your modules; thanks. For those who haven't done it
yet; get busy. ;)

Richard

[1] https://wiki.gnome.org/GnomeGoals/AppDataGnomeSoftware
[2] 
https://raw.github.com/gnome-design-team/gnome-mockups/master/software/version2/software-fonts.png
[3] https://bugzilla.gnome.org/browse.cgi?product=gnome-software
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: GNOME Software

[Richard Hughes]

On 24 September 2013 15:29, Olav Vitters o...@vitters.nl wrote:
 Is there anything a distribution should do? I noticed you wanted
 something changed in the Fedora build system. Did I have that right and
 do we need similar changes in other distributions?

Well. The issue is more how we describe things like input methods.
I've got a nice set of files
https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra/inputmethod
that are headed upstream, but I've kinda fudged the AppStream side of
things. I'll have to add to the official spec so we can be
interoperable between distros. Actually running the build and compose
steps on the distro servers (rather than running it myself once a week
or so) and that's something I'll be pushing for after F20 is out of
the door.

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

Re: Opening the 3.12 cycle

[Richard Hughes]

On 23 September 2013 14:46, Frederic Peters fpet...@gnome.org wrote:
 This could also come after a review of the appdata schema, for things
 like screenshot translations.

The screenshots are translatable now, you just use a _screenshot
link and change any en_US in the URL to your country code if a
screenshot exists. I don't think we want to make this compulsory, it's
quite a high bar to set.

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

Re: GNOME Software Center and YOU!

[Richard Hughes]

Hi all,

A progress update: lots of upstreams have already merged AppData files
(50 and counting!) but we're still a long way from having all the core
moduleset modules with AppData files. For some of the more important
modules I've setup a google document here:
https://docs.google.com/document/d/1X4SBZM44ZIWM7s8_dgKw51aZfw0amp3fsqLVUPty5Gs/edit

This is important for gnome software because even though the core
modules are non-removable, they still show up in the update and detail
view and it would be really good to match the mockups provided by
Allan for 3.10.

Once we've got some more contributions and the editing has settled
down, I'll be pestering the upstream GNOME maintainers to ship the
user-contributed extra data upstream for all distros to use. Feel free
to add extra applications to the google document if your module is not
listed there, or just create an AppData file yourself, commit it
upstream and add a link on the document.

Thanks again!

Richard

On 29 August 2013 21:07, Richard Hughes hughsi...@gmail.com wrote:
 Do you maintain an application that people use? Do you want people to
 be able to install it easily in the GNOME Software Center?

 If both of those are true, please read the newly finalised AppData
 specification [ http://people.freedesktop.org/~hughsient/appdata/ ]
 and ship one tiny extra file in your tarball for 3.10.

 People will love you for doing it, and I’ll really appreciate it.
 Maybe post 3.10 we can do a GNOME Goal for all the core GNOME modules,
 but of course this applies to GNOME, KDE, XFCE and random standalone
 apps.

 Any questions, send me email or grab me on IRC. Thanks!

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

Re: GNOME Software Center and YOU!

[Richard Hughes]

On 30 August 2013 15:08, Simon Kågedal Reimer skage...@gmail.com wrote:
 I made a RELAX NG schema for this format.

Awesome, thanks. Any chance you could write a patch for the spec
document? It's hosted here: https://github.com/hughsie/appdata-website
-- probably just adding the file and adding an entry in the FAQ
section is enough.

 Don't quite
 understand what the relation between AppStream and AppData is.)

My AppStream compose tools do something like this:

for each package in distro:
   extract .desktop files
   extract .appdata.xml files
   write appstream.xml file
xmlmerge all the appstream.xml's files together into a master
appstream.xml and optionially gzip it

So really, the data in the AppData is used to make the AppStream data
more complete. AppData is just another data provider just like the
.desktop file.

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

GNOME Software Center and YOU!

[Richard Hughes]

Do you maintain an application that people use? Do you want people to
be able to install it easily in the GNOME Software Center?

If both of those are true, please read the newly finalised AppData
specification [ http://people.freedesktop.org/~hughsient/appdata/ ]
and ship one tiny extra file in your tarball for 3.10.

People will love you for doing it, and I’ll really appreciate it.
Maybe post 3.10 we can do a GNOME Goal for all the core GNOME modules,
but of course this applies to GNOME, KDE, XFCE and random standalone
apps.

Any questions, send me email or grab me on IRC. Thanks!

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

AppData proposal

[Richard Hughes]

Hi all,

I've written up a specification that I would like to get feedback on.
It's had a few iterations now, and soon I'd like to propose a GNOME
Goal on adding the required files to at least all the apps in our core
moduleset.

The proposal is http://people.freedesktop.org/~hughsient/temp/appdata/

All comments welcome, thanks.

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

Re: AppData proposal

[Richard Hughes]

On 21 August 2013 13:47, Shaun McCance sha...@gnome.org wrote:
 If you use itstool, you don't have to mangle your input XML.

I discounted itstool as I didn't want *all* the elements translated.

 Regardless,
 you really ought to specify at what level you expect to see translatable
 elements repeated. Do you really want this:

 description
   pYelp is a help viewer./p
   p xml:lang=deYelp ist ein Hilfe-Viewer./p
   pIt's really cool./p
   p xml:lang=deEs ist echt toll./p
 /description

This, I guess, although I'm open for ideas.

 DOAP's concept of a project is pretty loose, and doesn't necessarily
 have to correspond to a tarball or a repository. There's no reason a
 package can't have one DOAP file for each application.

True

 One reason not to is that doing the kind of rich markup you have in the 
 description element
 is a pain in RDF.

RIght, this is/was a major factor.

 I went to the AppStream wiki page but didn't see a schema. Do you have
 more info yet?

I think this might help;
http://gitorious.org/appstream/appstream-core/trees/master/docs

Thanks for any help,

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

Re: AppData proposal

[Richard Hughes]

On 21 August 2013 14:35, Colin Walters walt...@verbum.org wrote:
 I think it'd really help a lot if we had a model where we figure out how
 to generate some of it from a canonical source.  For example, if we're
 now going to say that AppData is canonical, we should generate
 the .desktop file content from that.

That's a good idea, but I'm not sure if AppData wants to be a superset
of the desktop specification. I think it's related, but orthognal.
There are cases where you'd want a different name in an software
center to the search term in the shell, and other cases like that.
Taking that into account, I don't think it would share much at all,
and the additional dep of a tool to go from XML-desktop would
probably be too much for some projects.

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

Re: AppData proposal

[Richard Hughes]

On 21 August 2013 15:00, Jasper St. Pierre jstpie...@mecheye.net wrote:
 There are cases where you'd want a different name in an software
 center to the search term in the shell..
 Which case? I think any app that does that is broken.

TrackerGUI wants to be Search in the menu, but probably ought to be
Tracker in the software center. Similar for Videos - Totem.

 I also feel like the system of describing this application has to be done
 in a common format by one of other OS vendors. Have we looked into what
 Ubuntu, OS X, iOS, Android, and Windows do for this? Is it an XML-based
 format we can share?

I don't think it's worth the pain of interoperability just to share 2
or 3 fields, but I'm open for ideas if anyone has any more details of
something suitable.

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

Re: AppData proposal

[Richard Hughes]

On 21 August 2013 15:21, Shaun McCance sha...@gnome.org wrote:
 That's why itstool uses ITS.
 its:rules
   xmlns:its=http://www.w3.org/2005/11/its;
   version=1.0
   its:translateRule translate=no selector=/application/
   its:translateRule translate=yes
 selector=/application/name | /application/summary |
   /application/description/
 /its:rules

So where does that ITS snippet live? On each project or somewhere central?

 Here's the rub: When you have an element that can occur multiple times,
 it becomes difficult to reliably figure out which ones to show.

Agreed.

 You first have to figure out which are the source elements, then which
 translated elements correspond to which source elements. It's just very
 unpleasant to deal with repeated translated elements when they're used
 in a document-like markup, as opposed to an informational markup.

Dude, you outclass me completely when talking about XML stuff, so I'm
really open for your input. It sounds like what you'd like is:

* An untranslated .xml.in file
* itstool with the snippet used for translations

Any help welcome on what I should put in the specification document. Thanks.

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

Re: About clutter-gtk and his lack of accessibility support

[Richard Hughes]

On 14 February 2013 19:08, Matthias Clasen matthias.cla...@gmail.com wrote:
 gnome-color-manager-3.7.5-1.fc19.x86_64

This is using it for only one thing; the 3D gamut graph widget. Is
there a more supported way to define a custom GTK widget that lets me
embed a clutter actor? I'm using mash to render the 3D gamut model if
that matters.

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

Re: Preserved Window Placement

[Richard Hughes]

On 26 October 2012 15:07, Havoc Pennington h...@pobox.com wrote:
 This could be even higher-level in fact. All the app must do is specify
 which windows are the same from invocation to invocation. That is the
 fundamental problem (what is the key we are saving the window state
 underneath).  gtk_window_set_state_key() ? At that point GTK+ (in
 cooperation with the desktop e.g. WM, if you like) can do the actual saving.

I was wondering if we could do something using GtkApplication. It
seems a shame to reimplement this in every app when most apps have
just one window...

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

Re: Requiring systemd for the gnome-settings-daemon power plugin

[Richard Hughes]

On 19 October 2012 14:27, Sebastien Bacher seb...@ubuntu.com wrote:
 ..otherwise I will suggest we stop making GNOME available since Ubuntu
 doesn't have the requirements to run  3.8...

I'm sure I was talking to several people that managed to get
systemd/logind working just fine on Ubuntu. Can't the GNOME remix just
use systemd and the main spin just use upstart?

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

Re: GNOME and high-DPI screens

[Richard Hughes]

On 4 July 2012 10:52, Olav Vitters o...@vitters.nl wrote:
 Best to give developers high DPI screens (not kidding).

From my experience working with hardware, I could not agree more. 10 x
$500 screens sent to a few GTK developers would result in several
hundred-man hours of work done on the high DPI issue, most likely at
weekends and after work. If any manufacturer wants to make this stuff
work, spending a few thousand dollars on several hundred man hours of
work is a no brainer. Anyone from Dell or HP listening? :)

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

Re: Redesign Gnote as Notes?

[Richard Hughes]

On 21 May 2012 13:48, Matthias Clasen matthias.cla...@gmail.com wrote:
 Thanks for considering the new design. I would really love to see
 gnote move towards that, so that the many happy gnote users can remain
 happy in GNOME 3.

Yes, I'm a heavy gnotes user and would also appreciate the gnotes
codebase being transformed into notes. On a related topic, I'll buy
the person who makes my notes searchable from the shell several beers.

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

Re: Redesign Gnote as Notes?

[Richard Hughes]

On 21 May 2012 14:08, Will Thompson will.thomp...@collabora.co.uk wrote:
 That would be Casey Harkins:
 https://github.com/charkins/gnome-shell-extension-notesearch works with both
 Gnote and Tomboy.

Nirvana. Beer tokens to Casey. Thanks dude.

Richard.
___
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

[Richard Hughes]

On 21 October 2011 17:28, Piñeiro apinhe...@igalia.com wrote:
  * Repositories: right now it is on sourceforge. This shouldn't be a
 blocker thought.

I'm pretty sure it needs to be on git.gnome.org

  * Look and feel: some people could not agree with current interface
 [2]. This shouldn't be a blocker thought.
 This feature proposal would include the proposal of wxWidgets
 as a external dependency.

wxWidgets applications differ lots from native applications. I
really don't think depending on wxWidgets is a good idea.

 In addition to wxwidgets, eViacam has also dependencies with opencv and
 libv4l1, that should be included as external dependencies.

Shouldn't eViacam should be ported to libv4l2?

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

Re: Feature proposal: Braille Translator for Print Documents

[Richard Hughes]

On 21 October 2011 17:25, Piñeiro apinhe...@igalia.com wrote:
 This proposal would include a need to make liblouisxml a required
 external dependency. However, we do not think this will pose a hardship
 to distros as liblouisxml is liblouisxml is considered stable and in
 maintenance mode. [5]

I think liblouisxml is probably fine.

Richard.
___
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)

[Richard Hughes]

On 18 October 2011 16:52, Olav Vitters o...@vitters.nl wrote:
 Such actions just confirms that the effort was not an honest intention
 to gather feedback. Just to confirm own thoughts.

I don't think many of us on this list thought the intention of the
survey was to highlight areas needing improvement in GNOME. I think
it's best if we just let the Real Users comment on phoronix without
it getting into a huge troll-fest. That way there's no distraction for
us developers and designers who are working on GNOME 3.3.

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

Full screen color management

[Richard Hughes]

GNOME 3.2 is polishing up nicely, but some of us have twitchy fingers
and are looking forward to 3.4.

One of my goals is to complete the desktop color management work, and
bring OSX-style full screen color management to the GNOME desktop.
This means doing full screen color management on the GPU, probably
using a GLSL shader. If hardware shaders are not supported, then we
can fall back to just uploading the VCGT gamma ramps like we're doing
in 3.2.

So, what does FSCM actually bring us? On newer LED hardware you have a
much larger gamut (range of colors) and so artwork designed for a
1990's style CRT gamut is going to make all the colors painful and
give everyone headaches. It allows us to make dual monitors look the
same, and even allows us to make the colors more accurate on shitty
TFT panels. It means we can have full screen movies with the right
colors without everything looking either overly saturated or washed
out.

It also means that we have to think about;

* Word processing applications can just ignore color management
completely and just output everything as sRGB which gets converted to
something sane (which doesn't make your eyes bleed) by mutter.

* Full screen power applications that care, e.g. blender, can opt-out
the whole window and get to do all the color management stuff
themselves.

* Games running full screen just get to tell the compositor to
naff-off and let the game use all the texture memory (each loaded
color profile is currently stored as 16x16x16 which is ~3Mb).

* Mixed content applications like Firefox only opt out regions of the
window, e.g. when browsing Flickr, and only one image is color managed
and the rest of the page is sRGB.

This is basically what OSX allows you to do. I appreciate bringing
this to Linux/GNOME is no mean feat, but all of the groundwork was
done for 3.2. I also want to do something that's easy to use, so
rather than having blender do some archane thing with some random
library we just tell it to use
gtk_window_enable_color_management(window, FALSE); or the alternative
in Qt.

So, basically, is this something we want? I've got some PoC patches
for mutter but they are just hacks that show we can do FSCM without
hurting UI latency or without burning loads more power. If this is
something we want, then we have to decide on the integration points
for GTK and mutter and how do do the opt-out of windows and regions.

Ideas and feedback welcome. Thanks.

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

Re: Full screen color management

[Richard Hughes]

On 6 September 2011 13:40, Emmanuele Bassi eba...@gmail.com wrote:
 oh, you wanted *actual* proper feedback? ;-)

Yes! :-)

 how is the shader approach structured?

Well, at the moment the test code is a fragment shader which is
attached to each actor using clutter_actor_set_shader (which I notice
is now deprecated). I was going to wrap all the color stuff up in a
GcmIccEffect and just add an effect to each actor. The question then
becomes what to do with an actor that straddles two outputs in a
multhead setup. Logically it makes sense to cut the actor up and use
the correct screen profile on each part (using a 1bit bitmask or a
uniform xoffset in the shader perhaps?) but it might be simpler just
to choose the output profile that the actor most covers.

As for masking out areas that already have color correction, I'm not
sure. I'm tempted to just opt-out whole actors at the moment, although
from a mutter point of view that means you don't get color corrected
toolbars and that kind of thing. This can be quite a gradual thing, we
don't have to do everything at once as long as we've got an good
opt-out story for the Pixars and Dreamworks of this world.

Richard.

p.s. the test code I'm using is
http://git.gnome.org/browse/gnome-color-manager/tree/tools/gcm-glsl-demo.c
although this will change quite a lot in the next few weeks.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Full screen color management

[Richard Hughes]

On 6 September 2011 14:27, Bastien Nocera had...@hadess.net wrote:
 Given that we now use a Clutter based sink in Totem, Cheese and Empathy,
 does this mean that we could drop per-application
 brightness/contrast/etc. tweaks, if they were to be done desktop-wide?

Well, color-management and tweaking is kinda orthognal in that the
former is interested in precise color matching and the second is about
making things look a little better to a certain person.

The end-goal for color management is to not need to tweak stuff, and
for the film to come with an embedded profile (or at least a hint,
like I'm a PAL DVD) and the screen to be calibrated, which means
that the colors just look as close to ideal as possible.

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

Re: TARBALLS DUE: GNOME 3.1.90 beta release, and freezes

[Richard Hughes]

On 28 August 2011 08:18, Frederic Peters fpet...@gnome.org wrote:
 We pushed it back to make it rock, so we count on you to deliver your
 tarballs on time, this is before Monday 23:59 UTC. Thanks!

Monday is a bank holiday in the UK, so I have to work on my day off or
will early morning Tuesday be acceptable? I don't mind the former if
it's a hard requirement. :-)

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

Re: GNOME user survey 2011 (v4)

[Richard Hughes]

On 19 August 2011 14:13, Felipe Contreras felipe.contre...@gmail.com wrote:
 Is there anyone in the universe able to create a user survey worthy of
 GNOME? Can you convince him of doing so?

Do your survey with the questions you want, and come to your own
conclusions. Blog about them if you want. You could even convince a
distribution to include a popup with a link, although I think that's
insane.

Just don't tell people that it's from the GNOME project, in any way
authorized or blessed by the ruling cabal[1] or developers. I'm pretty
sure the majority of the people actually working on GNOME 3.2 don't
want a survey at all.

Sorry to be blunt.

Richard.

[1] http://ftp.gnome.org/conspiracy/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Richard Hughes]

On 19 August 2011 18:42, Felipe Contreras felipe.contre...@gmail.com wrote:
 Sure, I just wanted to make things clear. In fact, if they cared about
 user feedback, there would be some numbers available somewhere, and I
 wouldn't have to do this.

We're not asking you to do anything. Please just run the poll on your
personal blog and stop getting aggressive with developers on this
mailing list.

Thanks,

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

Re: GNOME user survey 2011 (v4)

[Richard Hughes]

On 19 August 2011 20:26, Felipe Contreras felipe.contre...@gmail.com wrote:
 ...To me GNOME is hitting
 everything in the room as it's going forward, and saying; I'm fine, I
 know where I'm going...

To me, the sun is shining through the windows of a freshly redecorated room.

If you have specific problems with GNOME, file bugs and discuss things
with maintainers and designers. It'll be way more effective at
changing things than writing a survey.

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

Re: Formal complaint concerning the use of the name System Settings by GNOME

[Richard Hughes]

On 4 August 2011 07:27, George Spelvin li...@horizon.com wrote:
 I think what is needed is a series of more specific alternate names in
 a .desktop file, with more levels than the current GenericName and Name.

I think the KDE system settings desktop file just needs an addition of:

OnlyShowIn=KDE;

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

Re: GNOME user survey 2011

[Richard Hughes]

On 1 August 2011 11:20, Christophe Fergeau t...@gnome.org wrote:
 Once again, I think things will go this way, we run the poll, maybe 1%
 of gnome users answer, N% of these respondants answer X, and then
 we'll get people saying N% of GNOME users want X, upstream ignore
 their users!

To upstream maintainers, even a user survey telling us to do X, Y or
Z is probably going to be ignored. Users don't know what they want[1].

Richard.

[1] A very popular request in gnome-power-manager is a command to be
executed when the brightness keys are pressed, which allows vendors to
hook up custom notifications, and people using odd proprietary drivers
to execute crazy stuff like nvclock or radeontool to actually poke
semi-random numbers into hardware registers using a setuid script.
This means we then have n*n*n hardware interactions, on the assumption
that the hardware already has n*n ways of notifying userspace
[hw+changed, changed, hw, neither].
What the user really wants is brightness control to just work, which
involves making the xorg driver vendors implement either XBACKLIGHT or
the drm driver just to add a standard sysfs backlight class device,
which means that no hacky code is required at all. It's really hard to
write a kernel or xserver patch, but it means that stuff just works,
and gives us a platform we can realistically support.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new jhbuild features: jhbuild sysdeps and partial_build = True

[Richard Hughes]

On 29 July 2011 05:53, John Stowers john.stowers.li...@gmail.com wrote:
 This doesn't currently work on non-packagekit system, such as Ubuntu. I 
 created

You can use PackageKit on Ubuntu, it works fine. It's just not
installed by default, which is unfortunate.

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

Re: On the Interaction with the design team

[Richard Hughes]

On 1 June 2011 12:57, Matthias Clasen matthias.cla...@gmail.com wrote:
 Basically, mailing lists don't work for many kinds of productive discussion.

Agreed. In my recent discussions with the dudes in #gnome-design there
was a flurry of messages, perhaps as many as 200 back-and-forth
discussions per hour. In that same hour, we iterated about 20
screenshots and quite a few designers piled in with suggestions.

You just can't get that kind of latency and interest level with a mailing list.

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

Re: gnome-power-manager 3.0.2

[Richard Hughes]

On 23 May 2011 10:18, Richard Hughes install-mod...@master.gnome.org wrote:
 http://download.gnome.org/sources/gnome-power-manager/3.0/gnome-power-manager-3.0.2.tar.gz
   (4.81M)

I've noticed that mails are being now sent automatically to
ftp-release-list -- are we still supposed to send mail manually to
gnome-announce-list? It seems somewhat redundant to do it twice.

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

Re: Reminder: new uploads ftp.gnome.org will have .tar.xz and .tar.bz2 (May 25th)

[Richard Hughes]

On 21 May 2011 14:34, Olav Vitters o...@vitters.nl wrote:
 As from May 25 (once GNOME 3.0.2 stable has been released), new tarballs
 on ftp.gnome.org will be uploaded as:
  - .tar.xz
  - .tar.bz2

 Meaning: no more .tar.gz for *new* uploads.

So does this mean for the release on Monday we should now change
AM_INIT_AUTOMAKE to be no-dist-gzip dist-xz ?

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

Re: 3.2 features: color management

[Richard Hughes]

On 20 May 2011 13:24, Matthias Clasen matthias.cla...@gmail.com wrote:
 Over the past week, Richard and I have spent a lot of time in
 #gnome-design, discussing the goals and design for a 'color'
 control-center panel. This was hard; color management is a very
 technical topic.

I just wanted to thank all the people in #gnome-design for their
patience and support - color is indeed hard for mere mortals to
understand.

When I've pushed some of the initial code into gnome-control-center
and gnome-settings-daemon I'll post some screenshots of what it looks
like.

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

Re: 3.2 features: color management

[Richard Hughes]

On 20 May 2011 14:31, Luca Ferretti lferr...@gnome.org wrote:
 In GNOME 3.2, colord is an approved external dependancy and many GNOME
 applications should use this to make a 100% color managed desktop.

 Ehmm.. is? really?

I sent an email to DDL prior to the release of 3.0 that colord would
be a dep for gnome-color-manager in GNOME 3.2. Nobody at all
complained. I've repeatedly asked people to package it, and since LGM
it's been appearing in other distros slowly. It's not on
ThreePointTwoExternalDependencies wiki page as I can't see that one
exists yet.

The quieten everybody down, colord compiles just fine on the BSD's and
on Solaris, although without xrandr, udev and sane integration, it
doesn't really do anything interesting at all. :-)

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

Re: 3.2 features: login screen

[Richard Hughes]

On 20 May 2011 14:44, Luca Ferretti lferr...@gnome.org wrote:
 Now serious, I repeat. We still have to define what GNOME OS will be. So
 I suggest to use 3.2 timeframe to clean up applications and libraries
 instead starting to work on downstream stuff. Do you?

I thought 3.0 was all about getting our platform in order, and 3.2 was
all about defining the OS properly. I don't think that was written
down anywhere, but that was the vibe I was getting.

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

Re: 3.2 features: color management

[Richard Hughes]

On 20 May 2011 13:38, Richard Hughes hughsi...@gmail.com wrote:
 When I've pushed some of the initial code into gnome-control-center
 and gnome-settings-daemon I'll post some screenshots of what it looks
 like.

Okay, I've pushed the code to g-s-d and g-c-c just now. Thanks to
Bastien and Matthias for the super-quick reviews!

You can see a screenshot here:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=188165

If you're testing the new code, be sure to grab colord from git
master, as Bastien wanted me (correctly) to push some of the helper
code down into libcolord. Also, don't try to calibrate just yet, it's
known broken. When I've untangled gnome-color-manager the gcm-prefs
binary will be deleted, and a gcm-calibrate binary will show up for
g-c-c to use.

If you've got comments about the UI, please either grab one of the
guys in #gnome-design, or one of the gnome-color-manager developers in
#gnome-color-manager.

Thanks,

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

Re: GNOME Feature Proposal: Backup

[Richard Hughes]

On 10 May 2011 20:10, Bastien Nocera had...@hadess.net wrote:
 You'd need to ask Richard. I think the only reason it's not builtin to
 the control-center is because it didn't go through design, but I might
 be wrong.

Well, I got shafted in GNOME 3, as I was told I shouldn't have
installed a panel in the control panel without getting approval, and
then the package got dropped by default in Fedora as it didn't fit in
the design guidelines and we were already past the UI freeze. I guess
I'm just a little bitter in retrospect.

At the moment I've removed both the Working spaces and Rendering
intent tabs as they didn't make much sense. I really want to better
emphasize the need for a color managed workflow (where each input,
display and output devices) have assigned profiles rather than split
up the color profile assignment into the separate display, printer and
unknown-type current panels and perhaps the current UI doesn't reflect
that very well. 3.2

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

Re: Fix gsettings path to use /org/gnome instead /apps

[Richard Hughes]

On 24 March 2011 22:41, Luca Ferretti lferr...@gnome.org wrote:
 [3] actually it misses a patch for org.gnome.packagekit.gschema.xml

I've made this change in gnome-packagekit in git master, let me know
if we get a freeze exception for this and I'll cherry-pick into
gnome-3-0.

Thanks,

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

Re: Fix gsettings path to use /org/gnome instead /apps

[Richard Hughes]

On 25 March 2011 13:37, Luca Ferretti lferr...@gnome.org wrote:
 Yes, freeze exception granted, feel free to change :)

I've pushed updates to gnome-3-0 for gnome-power-manager,
gnome-packagekit and gnome-color-manager.

Thanks,

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

Re: GNOME 3.2 ideas and plans

[Richard Hughes]

On 23 March 2011 11:08, Allan Day allanp...@gmail.com wrote:
 Software aside, we really need that new version of the HIG that we've
 been talking about (Calum has been taking this forward recently)!

In related news, I have no idea what the HIG is supposed to be for
3.0. Some control center panels have gray labels without the colon,
some have black labels with the colon. Some are right aligned, some
are left aligned.

I'm sure I'm not the only one who's quite confused.

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

Re: install-module / ftp.gnome.org / master.gnome.org

[Richard Hughes]

On 2 March 2011 11:30, Frederic Crozat f...@crozat.net wrote:
 I'd say let's stick to .bz2 only for now.

Makes sense to me. Fedora certainly uses .bz2 in preference to .gz.

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

gnome-control-center network panel

[Richard Hughes]

If you're using the network panel in gnome-control-center, you need to
be _running_ the 0.9 version of NetworkManager daemon. If you're
compiling with JHBuild, then you're probably compiling against 0.9
already, but have a running 0.8 daemon and so the control panel will
be very bare. The API is quite different, and so a dialog is shown
warning the hapless user. Ideally distros like rawhide should be
shipping 0.9 pre-releases.

In the next few days I'll be adding the editing screens for static
IPs, and also adding the VPN code to actually populate the GUI.
Apologies for missing the UI freeze, but it's a very small part of the
UI. Hopefully we can get the network icon in the status area ported in
time for 3.0 too. Thanks,

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

Re: gnome-control-center network panel

[Richard Hughes]

On 22 February 2011 20:54, Emilio Pozuelo Monfort po...@ubuntu.com wrote:
 Are there tarballs for NM 0.9 already? And if not, do you know the plans for 
 the
 0.9 release?

No idea, sorry. CCing Dan Williams (maintainer).

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

Heads up: gnome-color-manager will need colord for GNOME 3.2

[Richard Hughes]

For GNOME 3.2, I would like gnome-color-manager to depend on a new
project called colord (also written by myself).

colord is a project which aims to be a simple system activated daemon
that maps devices to color profiles. colord will be used by CUPS to
color manage printers, and connects to various other system devices
too.

See http://colord.hughsie.com/ for more details.

Tarballs can be found here: http://people.freedesktop.org/~hughsient/releases/

Although the code for colord support (colord branch in
gnome-color-manager) is 95% functional, it's had zero testing, and so
I'm intending to ship a colord-less gnome-color-manager for 3.0. This
means color managed printing will have to wait until 3.2 as colord is
a prerequisite of that. The CUPS code for colord support (icc branch
in cups) isn't quite finished either, so it makes no sense to push
this into 3.0 at this stage

I know I'm announcing this very ahead of the required time, but I
wanted distros to start looking at colord and for super keen
distro-people to report any packaging problems early.

Feedback / questions welcomed. Thanks.

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

Re: Metacity towards GNOME 3.0

[Richard Hughes]

On 2 December 2010 09:13, Rodrigo Moya rodr...@gnome-db.org wrote:
 We have been moving all desktop-wide settings to
 gsettings-desktop-schemas, so I guess it makes sense to have them there,
 under org.gnome.window-manager (or something similar), and just have
 metacity and mutter depend on it

Yes, this is what I've done in gnome-power-manager,
gnome-settings-daemon and the control center, as they share keys.

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

glade3 is the recommended way to edit GtkBuilder files?

[Richard Hughes]

I can't get glade3 to build with jhbuild. It segfaults for me on
Fedora 14, in various different places doing different things.

It's also missing several of the new widgets added to GTK in the last
few years, e.g. GtkInfoBar and GtkComboBoxText. Is it still the
recommended way we create and edit GtkBuilder files?

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

Re: Session DBus protocol

[Richard Hughes]

On 26 October 2010 03:57, Ryan Lortie de...@desrt.ca wrote:
 In short, I actually have absolutely no complaints about how it works
 now.  Please disregard. :)

Cool, one less API break :-)

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

Re: Session DBus protocol

[Richard Hughes]

On 25 October 2010 21:01, Ryan Lortie de...@desrt.ca wrote:
 I am interested in adding support to GtkApplication.

In porting gnome-power-manager to GDBus, there was a lot of overlap
between the new GtkApplication stuff, and the gnome-session
functionality. It would certainly make sense to tie this together.

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

Re: G/tkApplication

[Richard Hughes]

On 19 October 2010 00:44, Ryan Lortie de...@desrt.ca wrote:
 The upshot, though, is probably that quite some application that were
 making use of the old GApplication have stopped working.

So... what versions of gtk+ and glib should GNOME 2.91.1 tarballs be
targeted against?

Can I just skip 2.91.1 tarballs and just ask people to compile
everything from git master?

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

Applets and GNOME 3

[Richard Hughes]

Okay, we all know applets are a naughty word with GNOME 3. What do we
do with them - delete them from git master? Would this be a
precondition on an project getting the badge of GNOME 3 ?

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

Re: Applets and GNOME 3

[Richard Hughes]

On 28 September 2010 12:58, Juanjo Marin
juanj.ma...@juntadeandalucia.es wrote:
 I thought we were going to distribute gnome panel and applets for some
 cycles before dropping them out.

If that's the plan, then we need some kind of time limit, and we need
to build the old libraries with gtk3 [world of pain].

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

Re: GApplication is going away

[Richard Hughes]

On 3 September 2010 07:20, Ryan Lortie de...@desrt.ca wrote:
  totem, gnome-color-manager, eog, nautilus

gnome-color-manager on gnome-2-32 only references GtkApplication in
NEWS, and so is a false positive.

You know, for the next release when somebody says Hey, I've merged
cool-new-feature, please update your modules to use it I'm going to
be much more cautious than I was in 2-32. I've been burnt four times
in one cycle (GtkApplication, symbolic-icons, GTK 3.0,
libcontrol-panel).

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

2.91 tarballs?

[Richard Hughes]

For GNOME 2.32 I'm branching my modules from 2.30 and backporting easy
stuff from git master. 90% of my development effort is going towards
GNOME 3, which is happening on git master. Git master in most of my
modules depends on stuff like gtkapplication, gsettings, gdbus and the
new control center.

Should I release a 2.91.1 tarball soon which contains all the juicy
stuff as well as a 2.31.7 tarball which is ready for the release?
2.91.1 seems obvious from a this is GNOME 3 beta perspective, but I
would rather have some release team approval before I bump up the
minor version like that in git master.

If the answer is yes, then some other common GNOME modules that
provide libraries people need to use might also want to follow suit,
for instance gnome-desktop and gnome-control-center. At the moment,
it's a bit of mish-mash of versioning for post 2.32 versions.

Thanks,

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

Re: 2.91 tarballs?

[Richard Hughes]

On 9 August 2010 14:15, Vincent Untz vu...@gnome.org wrote:
 You can release 2.90.x (not sure why you'd want 2.91 before 2.90 ;-)).
 Some modules already have such versions.

90 is an even number, and thus 'stable', surely?

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

Re: 2.91 tarballs?

[Richard Hughes]

On 9 August 2010 18:36, Matthias Clasen matthias.cla...@gmail.com wrote:
 I have no problem with changing GTK+ to the 2.91 track

Okay, as I'm not happy changing 90 to be an odd number (:-) I'll use
2.91.1. Thanks.

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

Re: gnome-color-manager now requires lcms2

[Richard Hughes]

On 25 June 2010 07:35, Frederic Peters fpet...@gnome.org wrote:
 I realize now there has been no formal request to have lcms as an
 approved external dependency, probably because by the time it was
 requested I had a look and liblcms looked old, stable, and available
 in all distributions.

Right, I think even the GIMP has needed lcms for quite some time.

 Looks like this is not the case :/ So I'd like you to add liblcms to
 http://live.gnome.org/TwoPointThirtyone/ExternalDependencies and an
 entry in jhbuild moduleset; thanks!

Okay, sure thing. I'll do so this morning.

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

gnome-color-manager now requires lcms2

[Richard Hughes]

I've just switched gnome-color-manager in git master to require lcms2.
The author of lcms has switched development efforts to lcms2, and now
lcms1 won't get any new features or anything other than security bug
fixes. lcms2 is however parallel installable with lcms, so that makes
it easier on projects that already depend on lcms to migrate at a good
point.

lcms2 is quite a lot faster in my benchmarks, and does allow us to do
some cool things, namely manual calibration without a specrophotometer
(like OSX). Expect funky screenshots in the near future.

I hope this is okay, and should also give the few remaining distros
(cough, debian, cough) a push to finally package lcms2.

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

libnotify and GNOME 3

[Richard Hughes]

libnotify is the only major library that I'm unclear on for GNOME 3.
It's a conditional buildrequire in all my GNOME projects (as libnotify
still uses gtk2.0) and I'm sure we should have a more compelling
vision for notifications in GNOME 3.0. Does libnotify just require
building against gtk3 or do we need a bigger rethink?

I'm wondering if there has been any discussions on notifications or
even any API? Specifically for the shell I guess, but it would be nice
for it to work in a GNOME 2.x fallback environment too.

Thanks,

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

Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90

[Richard Hughes]

On 10 June 2010 12:24, Andre Klapper ak...@gmx.net wrote:
 This requires module maintainers to port their modules now (if you don't
 want an angry release-team mob soon in front of your house).

So, should we be requesting gtk3 = 2.90 in configure.ac now? At least
for Fedora rawhide the lack of gtk-engines makes all the gtk3-using
application look fugly.

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

Using GSettings to set for all users

[Richard Hughes]

I'm about ready to push my gsettings branch of gnome-power-manager
into master. The only remaining bits to port is the set default
button which sets the per-user settings for all users. This used to
work using the DBus interface of GConf (the policykit helper), but I'm
unsure on how to port this in a GSettings/dconf world. Ideas welcome.

Thanks,

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

Re: Modulesets Reorganization

[Richard Hughes]

On 2 June 2010 10:31, Luca Ferretti lferr...@gnome.org wrote:
 I.e. color management is of course really useful, but not needed to run
 a desktop session, isn't it?

I think the argument is that it's a framework (DBus interface) that
applications will be relying on, rather than a single application that
you start and stop.

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

Re: New module decisions for 3.0

[Richard Hughes]

On 2 June 2010 17:37, David Zeuthen zeut...@gmail.com wrote:
 The udisks codebase however isn't currently set up so it's easy to
 port the udisks codebase to, say, FreeBSD. But I'm planning to at
 least make that easier, I'm already busy porting it to use GDBus and a
 big part of that work is cleaning up the separation between the core
 service and kernel-OS-specific code.

The time between me adding the required separation and Makefile glue
and the FreeBSD UPower backend getting merged was a matter of weeks. I
think it's a classic case of taking the time for the first step and
then asking people to fill in the blanks.

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