Re: Changing version scheme for the evolution projects

[Jeremy Bicha via desktop-devel-list]

On Fri, Sep 16, 2022 at 9:41 AM Michael Catanzaro  wrote:
> In contrast, everyone knows how to handle alpha/beta/rc and knows what
> they mean. Just use tildes instead of periods in the appstream metadata
> (43~alpha, etc.)

Debian and its derivatives have a similar problem with the GNOME 40
style pre-release version numbering. We have to rewrite the versions
to use tildes instead of periods. It looks like Fedora is having to do
that too.

So we have a situation where it's requiring extra version mangling by
both distros and GNOME maintainers (to translate the version for the
AppStream metadata format), I believe distros have figured out
workarounds and updated their packaging scripts a while ago, but the
AppStream situation is probably needing manual work by GNOME
maintainers and mistakes are made.

I think we could save everyone some work by just making the tilde
style official instead of periods for pre-releases.

Thank you,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changing version scheme for the evolution projects

[Jeremy Bicha via desktop-devel-list]

On Fri, Sep 16, 2022 at 10:43 AM Michael Catanzaro  wrote:
> On Fri, Sep 16 2022 at 04:16:33 PM +0200, Jan Alexander Steffens via
> desktop-devel-list  wrote:
> > Arch changes prerelease versions as well, but we have to remove the
> > period (40.rc -> 40rc) so that it orders before 40 or 40.0.
> > A tilde is handled the same as a period and would not help us.
>
> Oh, sigh. I suppose if different distros have different ordering rules,
> then there is no way to please everyone.

$ git tag 44~alpha
fatal: '44~alpha' is not a valid tag name.

This may be related to some distro's challenges with tildes.

Debian's packaging scripts just converts the ~ to _ when tagging.

_ doesn't sort lower than a . so this still wouldn't fix the issue for
anything using git tag sort order to look up the newest version.

Thank you,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changing version scheme for the evolution projects

[Jeremy Bicha via desktop-devel-list]

Resending since my previous email went to the moderation queue.

On Fri, Sep 16, 2022 at 9:41 AM Michael Catanzaro  wrote:
> In contrast, everyone knows how to handle alpha/beta/rc and knows what
> they mean. Just use tildes instead of periods in the appstream metadata
> (43~alpha, etc.)

Debian and its derivatives have a similar problem with the GNOME 40
style pre-release version numbering. We have to rewrite the versions
to use tildes instead of periods. It looks like Fedora is having to do
that too.

So we have a situation where it's requiring extra version mangling by
both distros and GNOME maintainers (to translate the version for the
AppStream metadata format), I believe distros have figured out
workarounds and updated their packaging scripts a while ago, but the
AppStream situation is probably needing manual work by GNOME
maintainers and mistakes are made.

I think we could save everyone some work by just making the tilde
style official instead of periods for pre-releases.

Thank you,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Games in need of maintainers

[Jeremy Bicha]

On Mon, Aug 5, 2019 at 5:11 PM Arnaud Bonatti via desktop-devel-list
 wrote:
> I’ll take care of Four-in-a-Row, I have big plans for it.

Ok, you can start by doing a 3.33.90 release for it. 

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

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 8:47 AM Georges Basile Stavracas Neto
 wrote:
>  * It was never my intention to make GNOME To Do a core app, and I was
>glad to see it being dropped from the core set. For various reasons,
>both technical- and design-wise, I believe To Do wasn't a good fit.

Thank you for your reply. Ubuntu includes GNOME To Do by default in
18.04 LTS and still does. I guess we need to discuss whether it should
be removed by default, but we try to limit the adding and removing of
apps because of the disruption it causes to upgrading users. We added
it because we try to follow GNOME Core (for many reasons we are unable
to follow it completely) and we found the app fairly useful. We
appreciate you developing and maintaining it.

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

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 8:28 AM Debarshi Ray  wrote:
> The Todoist provider was always disabled by default. So unless a
> distributor enabled it by default, I don't see how that can happen.

That's an important point that I didn't notice before. Fedora and SUSE
kept it disabled; Arch, Debian and Ubuntu enabled Todoist. (In this
particular context, I was Debian and Ubuntu and Debarshi was Fedora.)

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 1:26 AM Debarshi Ray  wrote:
> You already attempted to slander me once before in this thread:
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html
>
> It's been one week since I produced evidence against that:
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html
>
> You had enough time to clarify your original statement or recant it. I
> no longer consider anything you say to be in good faith.

This feels like an awfully aggressive way of asking for a reply in a
heated thread that's already getting close to 100 emails. I don't know
if replying will help but since you seem to want a reply so badly and
because I do want to keep acting in good faith and not have our
relationship damaged over this, here's a reply.

> Select a recipe
> -> Buy ingredients
> -> View shopping list
> -> Share
> -> Add service
> -> Todoist

Your test case was so minimal that I didn't understand that's what it
was. Let me give a few more words. Step 0 is to build GOA with
--disable-todoist (if like me you're still using the stable version of
GOA). Then log out and log back in to make sure that you're using the
correct GOA service. The final step where you click the word Todoist
opens gnome-control-center to the Online Accounts page which does not
have a Todoist provider since we removed it in Step 0.

I did the test case a month and a half ago and drafted an email to you
to let you know about the 2 things I saw as mistakes in your commit
message but I decided it was too much like nitpicking for me to send
that email then. Maybe it would have been better if I had sent it
then.

> https://download.gnome.org/sources/gnome-todo/3.91/

Wait, GNOME To Do has one experimental release targeting GTK4 using
the same version number scheme as GTK4 and that's enough for you to
say that they are not following GNOME's Release Schedule? I think it's
reasonable to interpret the release number as a mistake (although a
fairly easy one to make given how GTK and GNOME release schedules have
been aligned fairly closely since 2011 and that the developer wasn't
around for GTK2). That version obviously isn't intended for distros to
ship and I think it's a reasonable way to identify releases in an
experimental series so that they don't conflict with new major
releases in the ordinary stable track. If you object to the version
number used, I encourage you to talk to the developer politely about
it.

I don't see a need to recant anything in my short original email. I'm
sorry that you feel so attacked in this thread and I apologize if my
replies or lack of replying feels like I'm trying to hurt you more.
That is not my intent at all.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Wed, Jan 23, 2019 at 2:47 PM Debarshi Ray  wrote:
> It's not like this is the first time we have dropped things from GNOME
> Online Accounts. Back in 2017 [1] we had dropped Telepathy. I had
> written a wall of text explaining that decision. Guess how many
> replies that thread got.  Surely, Telepathy has had a lot more users
> in its time than Documents.

I clearly remember the Telepathy removal from GOA. It made me slightly
uncomfortable that people would lose their account configuration on
upgrading, but at least Empathy still had a way to add those accounts
back. Empathy has lost so many users by now that I didn't receive any
complaints about that either.

But you're talking about removing even more online accounts providers
even though apps that support them have not yet implemented a
replacement. That's a completely different thing than a one-time
reauthentication after upgrading. (Google asks me for my password
frequently (at least monthly) in my web browser. I think users are
used to having to re-enter their password periodically.)

And it's not just Documents. I'm a bit concerned over the user
experience for Evolution if Fedora (or GNOME!!) removes the GOA
support for email. I know that Evolution has its own accounts system.
I'm just not sure that Evolution is designed to handle adding a
replacement account when the GOA provider is ripped away when users
upgrade.

I understand the user confusion problem about having additional
services and providers that are visible in GOA when the computer
doesn't have installed apps that use those. Ubuntu feels that even
more painfully than Fedora since we never included the Documents app
by default or Photos and Thunderbird (which doesn't use GOA) is our
default email client.

A few months ago, I talked with mpt about GNOME Online Accounts being
added to Ubuntu's version of gnome-initial-setup. I believe his
opinion was that the app itself should offer the "add a new account"
feature instead of the Initial Setup or Settings apps. If we wanted to
go that direction, we could make the Online Accounts panel be
integrated into the Applications panel (like we do in 3.32 with the
Location service).

Interestingly, Ubuntu Online Accounts was ahead of its time here. What
it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work.
You can select Google and see which apps support the Google UOA
service before signing in to the Google provider. Once signed in,
there are on/off switches for each app so you could have Evolution
have access to your Google account but not Shotwell if you wanted. If
we add portals for this, I think this could be very useful with
sandboxed apps.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Wed, Jan 23, 2019 at 9:34 AM Allan Day  wrote:
> It's important that we have the ability to correct problems when they
> do happen. To me that implies that only our software should use our
> keys.

You could also encourage distros to use their own keys.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Online Accounts 3.34 won't have documents support

[Jeremy Bicha]

On Thu, Jan 17, 2019 at 10:25 AM Bastien Nocera  wrote:
> On Thu, 2019-01-17 at 15:17 +, Debarshi Ray wrote:
> > It's been a month since GNOME Documents was removed from the set of
> > core utilities by the release team. See:
> > https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/157
> >
> > We are currently in the 3.31.x / 3.32 development cycle. Once the
> > GNOME 3.32 release is done, starting from 3.33.1, I will be removing
> > the GNOME Documents specific integration points from GNOME Online
> > Accounts because we no longer encourage distributors to ship this
> > application as part of the default set.
> >
> That also means that GNOME Documents is as good as dead if you do this,
> because the main use for it was to have a single point of entry for
> Cloud and local documents.

Similarly, Todoist support was dropped from GOA 3.32.

https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/bf77325d8

The commit message has a few mistakes: the Recipes app does not yet
have its own Todoist support. And it's wrong to say that GNOME To Do
does not follow the GNOME release schedule.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: App menu retirement: outstanding MRs

[Jeremy Bicha]

On Thu, Jan 10, 2019 at 8:13 AM Allan Day  wrote:
> Bastien Nocera  wrote:
> ...
> > The Videos change would also require a great deal of work
> I thought it was just shuffling some menu items around...?

My merge request was incomplete. It didn't handle the Python console
menu for instance. I submitted it anyway in case it would help someone
fix up the remaining issues.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moving keyboard shortcuts list from help to app (was: Retiring app menus - planning for 3.32.0)

[Jeremy Bicha]

On Sun, Dec 9, 2018 at 11:16 AM Jeremy Bicha  wrote:
> I've been adding the Keyboard Shortcuts dialogs to several games as
> part of the 3.32 app menu updates and I've run into this duplication
> issue. I'd like to remove the Keyboard Shortcuts page from the help
> for these games.

Here's what I'm doing now. I am removing the link so that the Keyboard
Shortcuts help page doesn't show in the default help view. (It will
still end up showing if you search for it.)

I did this so that we don't lose translations in case we end up
deciding we do want to duplicate the help after all.

I am doing some 3.31.3 tarball releases now since I know it's easier
for some people to test from a tarball than from jhbuild or bst or
whatever. So I think this will help the discussion.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gtranslator new release and rename

[Jeremy Bicha]

On Mon, Oct 15, 2018 at 8:42 AM Daniel García Moreno  wrote:
> With this new modernization we're thinking about change the name to
> something like "Gnome Translations", and maybe a logo redesign would be
> a good idea too.

You might be able to reuse the GNOME Translate name. It was used by a
different project last released in 2005.

https://www.nongnu.org/libtranslate/gnome-translate/

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gtranslator new release and rename

[Jeremy Bicha]

On Mon, Oct 15, 2018 at 8:42 AM Daniel García Moreno  wrote:
> Hi all,
>
> We've recover the gtranslator development and we've modernized the
> interface and fixed some bugs.
>
> Today we've an stable version that's a *lot better* than the old stable
> version from 2015.
>
> With this new modernization we're thinking about change the name to
> something like "Gnome Translations", and maybe a logo redesign would be
> a good idea too.
>
> Now I want to know what's the best way to release today. Should we go
> directly to gtranslator-3.30.2? Or should we wait for the next gnome
> release cycle to release a stable version?
>
> I want to push this new stable in flathub as soon as possible and try
> to update main distributions version of gtranslator.
>
> Regards.

You could still use the 3.30.0 number. That might be more appropriate
since it's the first release of this new series.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation - language default

[Jeremy Bicha]

On Thu, Apr 5, 2018 at 10:18 AM, Allan Day <a...@gnome.org> wrote:
> Michael Hall <mhall...@gmail.com> wrote:
> ...
>> We have a project
>> on GNOME's Gitlab, a Telegram channel, and have been trying to hold regular
>> meetings on it.
>
> This is all news to me... it would have been good to have heard about
> the initiative sooner - I've been involved in quite a few discussions
> about GNOME's developer documentation over the years, and have done a
> fair amount of work on developer documentation design in the past [1]
> (this came out of a meeting we had at GUADEC in 2016), including
> creating a new prototype site last year.
>
> Have you spoken with any of the relevant maintainers, like Shaun
> McCance, Frederic Peters, or David King? Christian Hergert's also done
> some work around developer documentation...

Let me confirm and restate: GNOME has a Docs team. It would be cool if
you would work with the existing Docs Team when doing big Docs stuff.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

logo.png for default avatar for GitLab repos

[Jeremy Bicha]

I found a small GitLab feature that I think can be useful for project
branding. I'm linking to it here for those who don't read Planet
GNOME:

https://jeremy.bicha.net/2018/01/30/default-avatar-for-gitlab-repos/

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, tips of the week and question of the week

[Jeremy Bicha]

On Fri, Jan 26, 2018 at 11:04 AM, Emilio Pozuelo Monfort
<poch...@gmail.com> wrote:
>> If you wanted an account at Salsa, you can use 
>> https://signup.salsa.debian.org/
>
> Who wants that? I think I got lost but I don't see the connection.

Someone said earlier that you needed to be logged in to see the
version number in Help. But yes, I wouldn't expect most GNOME
contributors to need a Salsa account.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, tips of the week and question of the week

[Jeremy Bicha]

On Fri, Jan 26, 2018 at 6:22 AM, Timm Bäder <m...@baedert.org> wrote:
> https://gitlab.gnome.org/help says 10.4.0

Does anyone know why the version number doesn't show up on
https://salsa.debian.org/help (I believe it's using GitLab CE 10.4.0)?

If you wanted an account at Salsa, you can use https://signup.salsa.debian.org/

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson support in Continuous

[Jeremy Bicha]

On Fri, Dec 1, 2017 at 9:39 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> On 29 November 2017 at 21:12, Emmanuele Bassi <eba...@gmail.com> wrote:
>
>> The build bot is currently busy rebuilding the whole of the manifest,
>> and I'm going to babysit it for a little while, so don't start
>> removing build-api wrappers or patches from the gnome-continuous
>> repository just yet; once the build runs through, I'll give the all
>> clear.
>
> All clear; you can start removing the `configure` build API wrappers
> from your projects, if you have them.

What about removing the gnome-continuous build-api patches? Are you
going to remove those or would you like maintainers to help remove
them?

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Jeremy Bicha]

On Sat, Nov 4, 2017 at 4:45 PM,  <mcatanz...@gnome.org> wrote:
> On Sat, Nov 4, 2017 at 2:41 PM, Florian Müllner <fmuell...@gnome.org> wrote:
>> Why is that in the list? I would expect most users to use the various
>> PrintScrn shortcuts for taking screenshots, which don't depend on
>> gnome-screenshot (anymore).
>
>
> Maybe we should drop it from core, then?

Well, based on Michael's original definition here, is it an essential
app without a popular drop-in replacement that seems to be unable to
be properly confined as a Flatpak?

Can it be confined by Flatpak?

I think that it is an essential app. Users expect to be able to take
screenshots and we should not expect users to use keyboard shortcuts
instead of regular apps. Personally, I don't recall hearing anyone
complain about gnome-screenshot being pre-installed and unremovable.

The list seems to be missing several core system utilities:
- Archive Manager
- Disks
- Disk Usage Analyzer
- Logs
- System Monitor

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Let's pause meson migration in preparation for the 3.26 release

[Jeremy Bicha]

Since we are now at the Freeze in the GNOME 3.26 Release Cycle, I am
requesting that we stop switching new modules to meson in the 3.26
branches. Specifically:

- If your module has autotools support as of this week's releases, please
don't drop it for 3.26 as some distros may be using that to build with,
regardless of what is listed in jhbuild.

- I think it may be a good idea not to introduce meson support for modules
now either.

If you want to do these things, please branch for 3.26 and make your
changes to git master for 3.27/3.28.

Please do continue to fix bugs in the meson build for your modules.

Thanks,
Jeremy bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.26 release notes

[Jeremy Bicha]

On Thu, Aug 10, 2017 at 3:59 PM, Leslie S Satenstein via
desktop-devel-list <desktop-devel-list@gnome.org> wrote:
> Regards from Mr. Rant.

Please stop replying to discussion threads with off-topic
conversation. Start a new thread instead with an appropriate subject
line.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Renaming a project

[Jeremy Bicha]

On Sun, Jun 11, 2017 at 7:15 AM, Sébastien Wilmet <swil...@gnome.org> wrote:
> - What to do about the git repo? Creating a new repo with the new name
>   and placing the old one in the deprecated section?

I believe you can push the new git repo.

Remember to update jhbuild
If your project was built by gnome-continuous (it doesn't look to me
like it is), you'd want to update that too.

Then file a bug like this:
https://bugzilla.gnome.org/769952

> - For the bugzilla product it's less important, especially if we move to
>   GitLab.

There isn't as much of a need for a bugzilla redirect and you should
be able to rename the bugzilla product yourself:
https://bugzilla.gnome.org/editproducts.cgi?action=edit=gtef

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Brasero shouldn't look for dvdcss_inerface_2

[Jeremy Bicha]

On Sun, Mar 26, 2017 at 9:19 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> thanks for the patch. Would it be possible for you to attach it to a
> bug on Bugzilla?

The tracking bug is https://bugzilla.gnome.org/show_bug.cgi?id=744916

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Jeremy Bicha]

On Fri, Mar 3, 2017 at 8:10 AM, Adrian Perez de Castro
 wrote:
> I do not use JHBuild, as I rarely need it — and when it may be needed, it
> feels clumsy. For 99% of my needs a ~130-line shell script [1] which sets
> the environment in a way similar to how JHBuild does is enough. I do not
> mind having to manually building a coupld of dependency modules now and
> then, as for me most of the time the distribution (Arch Linux) has recent
> enough packages.

You can use 'jhbuild buildone' if you don't want to build all the dependencies.

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

Which version of GTK+ for GNOME 3.24?

[Jeremy Bicha]

Will GNOME 3.24 target GTK+ 3.22 only or can we expect some modules to
require the new GTK+ 3.90?

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome personalisation

[Jeremy Bicha]

On Mon, Sep 12, 2016 at 11:46 AM, Michael Catanzaro
 wrote:
> On Tue, 2016-08-30 at 12:48 +0200, audio fan wrote:
>> I sit here with unnecessarily gigantic icons
>
> nautilus does have a setting to fix this! I turn it down one notch.

Ubuntu 16.10 Beta currently turns it down two notches by default (to
match its older behavior) and Ubuntu GNOME 16.10 turns it down one
notch.

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

Re: Keep shipping also generated gtk-doc html/ folder?

[Jeremy Bicha]

On Mon, Jun 27, 2016 at 1:34 PM, Simon McVittie
 wrote:
> Ubuntu deals with this slightly differently by nominating one
> architecture to be special (I think it might still be 32-bit x86, which
> was the most important architecture when Ubuntu started?), and only
> building the Architecture: all packages on that autobuilder, not the others.

As of Ubuntu 15.04, arch-independent packages are built as part of the
amd64 build.

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

GNOME Games source name

[Jeremy Bicha]

It's very confusing to have a new app whose source is named
gnome-games [1] since that name was already used not that long ago.[2]

On Debian and derivatives, gnome-games is still in active use [3] as a
metapackage for those who would like to easily install all of the
games in the gnome-apps moduleset.[4]

As far as I know, the new gnome-games has not been picked up by
distros yet, so a rename now should be minimally disruptive. Note: My
objection here's isn't to the display name of "Games" or "GNOME
Games". I believe the source package needs a different name though.

A quick look at the description field of the git repo suggests one
potential new name: gnome-games-launcher.

Thanks,
Jeremy

[1] https://git.gnome.org/browse/gnome-games
[2] https://download.gnome.org/sources/gnome-games/
[3] https://packages.debian.org/unstable/gnome-games
[4] https://wiki.gnome.org/Attic/Games
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]

[Jeremy Bicha]

On 16 August 2013 07:48, fr33domlover fr33domlo...@mailoo.org wrote:
 True, I don't suggest to prevent the mirrors: Just not automate. Anyone
 can create a mirror manually, and it's their freedom to do so. But I
 don't think maintainers should have their modules automatically synced
 to GitHub without allowing them to switch it off.

May I suggest that you read the GPL[1] again?

Term #1 of GPLv2 says, You may copy and distribute verbatim copies of
the Program's source code as you receive it, in any medium.

A maintainer of a GPL v2+ module has absolutely no right to stop
anyone making a public exact copy of the software (automatic or
otherwise). The license does not allow him to discriminate against
companies that he doesn't like. See also #5 and #6 of the Open Source
Definition.

[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
[2] http://opensource.org/osd

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

Re: Porting GNOME to Wayland

[Jeremy Bicha]

On 15 March 2013 14:32, Matthias Clasen matthias.cla...@gmail.com wrote:
 As far as a roadmap is concerned, I am fairly optimistic that we can
 have gnome-shell work as a Wayland compositor within 6 months. That
 will allow us to have optional Wayland support in GNOME 3.10, while
 still using X by default. Reaching this milestone by 3.10 will enable
 experimentation with Wayland, and should help us to take the next step
 for GNOME 3.12: a fully converted desktop, with no regressions. If we
 realize during 3.12 development that we won't be able to close all
 feature gaps in time for 3.12, it should be possible to keep
 gnome-shell on X for one more cycle without affecting the rest of the
 desktop too much.

Hi, just to clarify: For 3.12, you would like to drop support for
running gnome-shell or mutter on X directly and only support Wayland?
I understand that X apps will still run on top of GNOME Shell on
Wayland.

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

Re: Blocker bug review for 3.8

[Jeremy Bicha]

On 4 March 2013 23:57, Matthias Clasen matthias.cla...@gmail.com wrote:
 * related to feature 'drop fallback mode / add classic mode':
 688665  gdm drop gdm fallback session

Given that drop fallback mode is an anti-feature, I have a hard time
considering that bug as a 3.8 blocker. It sounds like the maintainer
wants to keep gdm fallback somewhere so killing it before we've
identified the right place to put it isn't helpful.

Also, we should have been frozen for the past 2 weeks; this type of
invasive change should be done sooner in the cycle. Making major
changes after the Freeze like this makes it very difficult for us to
ship the latest GNOME promptly in Ubuntu (since the Ubuntu GNOME team
shares responsibility for half of the GNOME stack with the Ubuntu
Desktop team).

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

Re: Blocker bug review for 3.8

[Jeremy Bicha]

On 5 March 2013 10:46, Matthias Clasen matthias.cla...@gmail.com wrote:
 If you want to keep fallback mode alive, I suggest getting engaged in
 building that right place - this bug has been on the 3.8 blocker list
 since before Xmas, so it is not exactly news that we were going to do
 this...

You can't break the Freeze just because you told people you were
planning to do something months ago. There is a Freeze Break procedure
and it should be followed if this change needs to be done now.

 Out of interest, who is in that team, apart from you ? So far, I've
 only associated your name with 'Ubuntu GNOME'

Currently the other developers are Rico Tzschichholz (ricotz) and Tim
Lunn (darkxst). Several GNOME packages are co-maintained with the
Ubuntu Desktop Team though. More volunteers are welcome since like
many open source projects, we are undermanned.

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

Re: Blocker bug review for 3.8

[Jeremy Bicha]

On 5 March 2013 13:13, Jasper St. Pierre jstpie...@mecheye.net wrote:
 What's the specific freeze break? Dropping the simple-greeter from gdm?
 Dropping gnome-panel, etc. from the official module set? We're not in hard
 code freeze yet, and neither of these are UI freeze breaks, as far as I
 understood it.

Dropping the simple greeter from gdm breaks feature freeze. Removing a
feature is even more disruptive than adding a feature so I thought it
was understood that we shouldn't be doing these changes after feature
freeze without getting approval. (For instance Debian Wheezy ships the
simple greeter by default.)

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

Re: gnome-Session

[Jeremy Bicha]

On 26 January 2013 18:30, Lanoxx lan...@gmx.net wrote:
 Also there is no man page for gnome-wm what does it do?

gnome-wm is a Debian-specific modification to allow users to easily
use a different window manager with GNOME 2 or GNOME Fallback:

http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-session/debian/scripts/gnome-wm?view=markup

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

Re: Using the Unicode ellipsis (…) instead of three periods

[Jeremy Bicha]

On 4 December 2012 09:21, Shaun McCance sha...@gnome.org wrote:
 Is this really the right thing to do. Even the Microsoft page
 uses the rather wishy-washy Consider using the ratio symbol,
 as if they're not quite sure this is a good idea. It does look
 nicer, but it's semantically wrong. A time is not a ratio. How
 does Orca read it?

Colon: http://bugzilla-attachments.gnome.org/attachment.cgi?id=230039
Ratio: http://bugzilla-attachments.gnome.org/attachment.cgi?id=230150

The biggest difference I see is that the colon sits on the baseline
while the ratio is nicely centered.

I like how Android 4.2 appears to use both styles: http://i.imgur.com/y2zVX.png

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

Using the Unicode ellipsis (…) instead of three periods

[Jeremy Bicha]

I think it's time that we move away from using three periods (...) to
represent the ellipsis and instead use the Unicode character (…).

This style has already been adopted by Microsoft [1] and Apple [2].

[1] 
http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode
[2] 
http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126

On the other hand, I think it's less clear whether we should change
command line output as the single Unicode ellipsis takes up
significantly less space than three periods in a monospace font.

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

questioning gnome modulesets

[Jeremy Bicha]

Core

My understanding is that the gnome-core moduleset contains the
essential pieces for distros to use to ship *GNOME*. Distros tend to
also supplement this with apps from the gnome-apps or gnome-world
moduleset or elsewhere (LibreOffice for instance).

Should epiphany (Web) really be part of GNOME Core? Most GNOME distros
(Debian, Fedora, openSUSE, etc.) use Firefox by default. Mageia is
notable for actually shipping Web. It seems to me like epiphany would
be better off in the gnome-apps moduleset, perhaps featured.

And what about gnome-packagekit? I don't think Mageia or openSUSE use
it by default and the Ubuntu GNOME Remix is planning to use Ubuntu
Software Center for its next release.

Apps

Why are Rhythmbox and Banshee in gnome-world and not gnome-apps?

Why are gnome-nettool and nemiver featured apps? What does featured
apps even mean?


I think we have a problem in that it's unclear how modules end up in
which sets and what those modulesets mean.

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

Re: GnomeGoal for 3.8: DesktopFileKeywords

[Jeremy Bicha]

On 14 November 2012 19:05, Jeremy Bicha jbi...@ubuntu.com wrote:
 On 4 November 2012 22:22, Matthias Clasen matthias.cla...@gmail.com wrote:
 We've had good success with 'adopting' a few GnomeGoals[1] as official
 targets for 3.6, and we want to repeat this for 3.8.

 And here are new goals that we want to tackle this cycle:

 DesktopFileKeywords - add a Keywords field to desktop files, to
 improve gnome-shell search for applications. This goal doesn't require
 any programming skills.

And one more suggestion: should GNOME Shell look at the Categories
field too? Specifically, typing in game doesn't really return
results now, even though the Games menu heading has several games
installed. Since most games available are not GNOME games, it may take
us a while before developers think about adding the Keywords field.

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

Re: GCalctool renamed to GNOME Calculator

[Jeremy Bicha]

On 13 November 2012 21:49, Robert Ancell robert.anc...@gmail.com wrote:
 I have renamed the GCalctool project to GNOME Calculator with the first
 release being 3.7.1 (we can now follow the GNOME numbering). The git module
 is now gnome-calculator (please now update translations/documentation there)
 and bugzilla will soon be moved to gnome-calculator.

Hey, when we do renames like this, should we also add a Keywords entry
to the .desktop so that people that try to type in gcalc… still find
the calculator they are used to? A related Ubuntu bug is
http://pad.lv/1041665 .

Also, my wife has the calculator pinned to her dash so, I expect when
she upgrades that favorite will disappear. That's something for
distro packagers to do some gsettings/dconf magic to help migrate,
right?

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

Re: GnomeGoal for 3.8: DesktopFileKeywords

[Jeremy Bicha]

On 4 November 2012 22:22, Matthias Clasen matthias.cla...@gmail.com wrote:
 We've had good success with 'adopting' a few GnomeGoals[1] as official
 targets for 3.6, and we want to repeat this for 3.8.

 And here are new goals that we want to tackle this cycle:

 DesktopFileKeywords - add a Keywords field to desktop files, to
 improve gnome-shell search for applications. This goal doesn't require
 any programming skills.

One thing that many module maintainers may be unaware of is that GNOME
Shell 3.6 no longer matches on comments so comments should be
converted to keywords. https://bugzilla.gnome.org/682529

A few months ago, I introduced keyword support to my wife as a way for
her to find apps by typing what she wanted to do. She immediately
tried typed in crop a picture which returned no results. Some of the
initial Keywords submissions (many from the Ubuntu community) don't
have verbs which I see as pretty important.

I also think GNOME Shell (and anything else that implements Keywords
.desktop support) should have a list of common connecting words which
it ignores. a, an, the is a good start. That blacklist should be
translatable.

Finally, I did a blog post about the Ubuntu desktop help (which is a
branch of the GNOME Desktop Help). I suggested that users type Help
into the Unity Dash to see the help. One of my readers doesn't use the
English locale and typing that in returned no results. I think we
should always show matches for the English name and keywords fields.
To take it one step further, it would be cool if translators could opt
in to a second language like this. For instance I suspect many
Tunisian users would like to see French results in addition to Arabic
results.

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

Re: 3.8 feature: Drop or Fix Fallback Mode

[Jeremy Bicha]

On 23 October 2012 04:20, Emmanuele Bassi eba...@gmail.com wrote:
 On 23 October 2012 07:30, Lanoxx lan...@gmx.net wrote:
 IMHO we should try our best keep gnome-panel alive for at least a few
 more years.

 there seems to be some confusion, here.

 removing the fallback mode in GNOME does *not* imply removing
 gnome-panel and metacity git repositories. what removing the fallback
 mode means is removing them from the release moduleset, as well as not
 trying to keep those modules up with the UX changes (an already
 arduous task as it is).

 if people want to keep maintaining those two projects for the people
 that prefer running them, they are *very* much welcome to do so —
 something that has been said multiple times already.

I believe it's quite a bit more than that. Dropping fallback mode
means ripping out the support code from
gnome-settings-daemon/gnome-control-center/etc. for the classic
desktop making it impossible to run with GNOME 3.8 or 3.10 or whenever
that happens. The tracking bug for that is
https://bugzilla.gnome.org/682858

As Unity currently depends on some of that code, this is a major
factor in pushing Ubuntu to ship the previous stable release instead
of the latest (in other words, GNOME 3.6 for Ubuntu 13.04). And as
currently set up, that means the Ubuntu GNOME Remix will be doing the
same.

I don't have a problem with dropping gnome-panel  metacity from core
to apps but killing it in this way is more controversial.

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

Re: jhbuild update required

[Jeremy Bicha]

On 5 September 2012 14:56, Colin Walters walt...@verbum.org wrote:
 Hi,

 TL;DR: Run git pull -r  make install in your jhbuild checkouts.

 The latest systemmodules work has landed in jhbuild; in the default
 configuration where modulesets are fetched via HTTP, the new ones will
 fail to parse with the old code.

Could we get a new jhbuild release then? Some distributions (Debian,
Ubuntu, openSUSE) have jhbuild packaged in their repositories.

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

Re: jhbuild update required

[Jeremy Bicha]

On 5 September 2012 15:13, Jasper St. Pierre jstpie...@mecheye.net wrote:
 jhbuild is not meant to be packaged. I'd highly suggest you stop
 packaging jhbuild.

Yes, you're not the only one to say that. But, I thought a big part of
what jhbuild offers is that it makes it relatively easy to try out the
bleeding edge of GNOME without having to mess with learning how to
./configure, make, make install (and of course ./configure doesn't
work on GNOME packages without running autogen.sh first but how's a
beginner to know that?). Requiring a beginner to manually build
jhbuild from source defeats that advantage.

Also, there's the whole problem of users needing to periodically
update their jhbuild manually. Why not let distros handle that like
they do every other package?

I've always ran jhbuild from the distro package. As long as jhbuild
gets regular releases, those releases get packaged, and I use the
default network modulesets, I don't see a problem.

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

Re: Recommended office suite?

[Jeremy Bicha]

On 4 September 2012 14:44, Hubert Figuière h...@figuiere.net wrote:
 AbiWord isn't developed within the Gnome infrastructure, therefore the
 fact it is not being discussed on Gnome mailing or others isn't an
 indication of it being abandoned - nor is the lack of update of the VERY
 BUGGY development snapshot that Ubuntu dare to ship.

The repeated criticism from Abiword developers towards Ubuntu for
daring to ship the software you released is getting pretty annoying.
Your stable release, 2.8.6 has known bugs, is over two years old, and
is not really supported. At least with the current development
version, we have a reasonable chance of getting bugs fixed. Ubuntu is
not the only one to package Abiword 2.9.* either. Please continue
releasing bugfix updates and every one will win.

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

Re: Recommended office suite?

[Jeremy Bicha]

On 3 September 2012 09:48, Justin Joseph justin.m...@gmail.com wrote:
 Jeremy Bicha said[1] that they will not include documtents in ubuntu-gnome
 as it depends on libreoffice. He later said that the way it is packaged
 right now in debian/ubuntu. I guess he is talking that comment.

Right, in Debian/Ubuntu, gnome-documents has a soft-dependency
(recommends) on unoconv which has a soft dependency on all of
libreoffice. In Debian  Ubuntu, recommends are installed by
default. I could push a Ubuntu package that drops one of those
recommends, but being able to open ODF formats is a nice feature. I
have to admit that I don't really understand what unoconv does or what
packages it actually needs.

 Anyways they are including mostly repo versions of gnome (nautilus 3.4,
 totem 3.4, shell 3.4, etc.). So nothing exciting for gonme fans, I guess.

I disagree. For one, we already have GNOME Shell 3.5.4 and I expect
that we'll be able to include GNOME Shell 3.6. Seb Bacher has
explained multiple times on this very mailing list why Totem 3.6 won't
be able to be included in the next Ubuntu release (dropped support for
gstreamer-0.10). Nautilus, Totem, and whatever other 3.6 components
that aren't included are a very easy install away from the GNOME3 PPA.
The PPA is recommended in our release notes.

Part of the reason for the Ubuntu GNOME Remix is to bring Ubuntu and
GNOME closer together again and I believe that is happening.

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

Re: Recommended office suite?

[Jeremy Bicha]

On 3 September 2012 02:12, Jasper St. Pierre jstpie...@mecheye.net wrote:
 LibreOffice is the supported and recommended office suite for GNOME.
 It works and is supported by most of the same developers as GNOME;
 there's no reason to create our own.

To be fair, abiword and gnumeric both show up in gnome-apps-3.6 in
jhbuild but LibreOffice is completely missing.

Perhaps this is unofficial but it should be corrected if it is
inaccurate: https://live.gnome.org/GnomeOffice

For GNOME2, Debian had a similar metapackage:
http://packages.debian.org/sid/gnome-office

And even for GNOME3, the Debian gnome metapackage depends on Abiword
 Gnumeric but a user can substitute LibreOffice.

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

Re: Prototyping navigation in Epiphany

[Jeremy Bicha]

On 6 June 2012 05:19, Bastien Nocera had...@hadess.net wrote:
 desktop-devel-list isn't the best place for design discussions though.
 #gnome-design on IRC, the usability mailing-list, and probably the
 epiphany mailing-list would be be better places.

But the usability mailing list gets very little traffic. I see only 1
email in the past 6 weeks.

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.

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

Re: GNOME Goal Proposal: Port to GMenu

[Jeremy Bicha]

On 26 April 2012 09:35, Allan Day allanp...@gmail.com wrote:
 On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote:
 Hi all,

 Last release we introduced the ability for applications to define a
 GMenu (or 'application menu'). This means that applications now have a
 place to locate global application (as opposed to per window) menu
 items. Some applications have already started to use a GMenu, and
 while this is great, it has also introduced some inconsistency (since
 some app menus have several items in them and some just have Quit).

 It would be great if we could improve on the current situation and
 ensure that all our applications present an appropriate set of items
 in their GMenu. I've started a GNOME Goal page [1] which we can use to
 coordinate this work, if people think it's a good idea.

 I'm not sure how good an idea this is given that the use of the app menu
 means that the application itself will require redesign. It would only
 be really useful for smaller applications with a very limited number of
 menu items, without a redesign.


 If an app has a complex menu bar, I'm recommending that it just moves
 a small number of items to the app menu (eg. new window, preferences,
 help, about, quit). That way we can ensure at least some consistency
 and prevent those oh, there's nothing there moments.

I don't know if Unity supports having both regular menus and a Gmenu
at the same time. Also, it's not consistent with the HIG (or much of
anything) to have Preferences be moved from the Edit menu. Maybe
Preferences could be *copied* to the app menu but that's not
necessarily a good idea either.

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

Re: GNOME Goal Proposal: Port to GMenu

[Jeremy Bicha]

On 26 April 2012 10:10, Jasper St. Pierre jstpie...@mecheye.net wrote:
 On Thu, Apr 26, 2012 at 10:04 AM, Jeremy Bicha jbi...@ubuntu.com wrote:
 On 26 April 2012 09:35, Allan Day allanp...@gmail.com wrote:
 On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote:
 Hi all,

 Last release we introduced the ability for applications to define a
 GMenu (or 'application menu'). This means that applications now have a
 place to locate global application (as opposed to per window) menu
 items. Some applications have already started to use a GMenu, and
 while this is great, it has also introduced some inconsistency (since
 some app menus have several items in them and some just have Quit).

 It would be great if we could improve on the current situation and
 ensure that all our applications present an appropriate set of items
 in their GMenu. I've started a GNOME Goal page [1] which we can use to
 coordinate this work, if people think it's a good idea.

 I'm not sure how good an idea this is given that the use of the app menu
 means that the application itself will require redesign. It would only
 be really useful for smaller applications with a very limited number of
 menu items, without a redesign.


 If an app has a complex menu bar, I'm recommending that it just moves
 a small number of items to the app menu (eg. new window, preferences,
 help, about, quit). That way we can ensure at least some consistency
 and prevent those oh, there's nothing there moments.

 I don't know if Unity supports having both regular menus and a Gmenu
 at the same time. Also, it's not consistent with the HIG (or much of
 anything) to have Preferences be moved from the Edit menu. Maybe
 Preferences could be *copied* to the app menu but that's not
 necessarily a good idea either.

 As I understood it, app menus were for all app-global things. If
 Preferences is app-global,
 it should be moved into the app menu.

I believe we were talking about keeping File/Edit/View while adding a
GMenu. If so, the UI would be quite confusing if some things were
taken out of the normal File/Edit/View menus. If all we're talking
about is how Epiphany 3.4 works, then that's fine but that's not how I
read what was written.

 And I thought that desrt and Colin worked very hard to have this work
 with Ubuntu. I remember
 Colin talking about how hard this was because of integration between
 GNOME 2, GNOME 3
 and Unity.

Unity supports GMenus as a replacement for the traditional
File/Edit/View menus, but I don't think it works as an addition at
this time. No app does that yet anyway.

On 26 April 2012 10:14, Bastien Nocera had...@hadess.net wrote:
 If it doesn't, there's fallback code in GTK+. But you should really
 point that out to Unity developers. On the GNOME lists, we tend to focus
 on GNOME itself.

Of course, GNOME decisions affect Ubuntu  Unity. I'm interested in
GNOME (Shell), GNOME Fallback (not for me personally but I help to
maintain it for Ubuntu users that want it), and Unity.

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

Re: 3.6 Feature: Lock Screen

[Jeremy Bicha]

On 25 April 2012 18:38, Marina Zhurakhinskaya mari...@redhat.com wrote:
 Technically, the code for fading out the screen and displaying the lock
 screen when the user becomes active again will be added to GNOME Shell, and
 the gnome-screensaver will no longer be used. The lock screen will be
 displayed within the same user session to enable the display of
 notifications. The lock screen will communicate with GDM via DBus to get
 authentication results.

 The look of the login screen will be changed too to have both look the
 same. The login screen is already implemented as part of the GNOME Shell
 code, and the common components will be shared, where possible.

When you say gnome-screensaver will no longer be used, what is your
plan for GNOME Fallback users? Also, have you thought about how this
would work for GNOME Shell users who happen to use LightDM or KDM or
something else?

And I wonder how this will affect Unity and Ubuntu 12.10. There's an
Ubuntu goal to use LightDM for handling the lock screen but I don't
know the technical details with that (whether it still needed
gnome-screensaver or not). I guess the bigger question is are you
really trying to deprecate and abandon gnome-screensaver in 5 months
or did I misunderstand?

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

Re: Module Proposal: Zeitgeist

[Jeremy Bicha]

On 22 April 2012 06:14, Olav Vitters o...@vitters.nl wrote:
 Risk for the feature focus is that the external dependencies rules are
 forgotten. E.g. I noticed that gnome-boxes increased its libosinfo
 version requirement in 3.4.1. That's not so nice when distribution is in
 a version freeze.

Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least
partly because the libvirt dependency was increased 2 weeks after The
Freeze. But this was the first stable release of Boxes, I'm sure
things will be better for 3.6.

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

Re: 3.6 Feature: Initial setup

[Jeremy Bicha]

On 21 April 2012 21:47, Matthias Clasen matthias.cla...@gmail.com wrote:
 We haven't really gotten off the ground with 3.6 feature proposals
 yet, so I'll make a start by announcing something that I hope to
 complete for 3.6: A nice initial setup experience.

 I have created a feature page describing this here:
 http://live.gnome.org/ThreePointFive/Features/InitialSetup

 The design can be found here:
 https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup

 The idea here is that we should help a user who boots his newly
 installed GNOME for the first time with the setup tasks that are
 necessary to make the system usable. Traditionally, this has been
 distribution territory, with various tools like firstboot that run at
 some point in the boot phase before the login screen. We can do a
 nicer job by replacing the login screen on the first boot, and we can
 make the transition from the initial-setup tool to the user session
 seamless.

 The design currently has screens for
 - network
 - user account
 - location/timezone
 - online accounts
 The idea is that we want to ask as few things as possible while still
 ending up with a system that is ready to use. We don't want to ask for
 settings which have good defaults or can be autodetected.

 The initial-setup support in gdm will be entirely optional, so
 distributions can continue to use their own mechanisms if they prefer.

This proposal assumes that Fedora's install procedure of ask some
questions, do the install, reboot, and ask more questions is better
than the install method used by OpenSUSE and Ubuntu of ask some
questions, do the install and reboot.

While the ask questions after install method is really convenient
for OEM installs, only a very small percentage of Linux installs are
done by OEMs. I think Fedora's install approach is more frustrating to
people that want to get using their computer as soon as possible.

If we ignore the OEM install use case, I think the remaining useful
pieces for a first-login experience would be allowing the user to
easily setup their online accounts and get an intro tour. These pieces
would be useful to any user's first login, not just the person that
installed the computer. In almost all cases, everyone using the same
computer would have the same location (i.e. time, language  keyboard)
 and basic network setup.

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

Re: Last GNOME 3.4 Blocker Report

[Jeremy Bicha]

On 20 March 2012 16:57, Shaun McCance sha...@gnome.org wrote:
 Yeah, but how many of those people are going to go to an About
 dialog. And if they do, are they really going to be any less
 confused by The GNOME Web developers? That sounds to me like
 the people who work on gnome.org. I wouldn't count on a stray
 capital letter to convey semantic information.

And as was already stated on the i18n list, there are billions of
people whose native language does not include capital letters.

Jeremy Bicha
___
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

[Jeremy Bicha]

On 20 January 2012 08:47, Ryan Lortie de...@desrt.ca wrote:
 hi Bastien,

 On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote:
 No, the distributions/systems that choose not to use systemd will have
 to provide a compatible D-Bus service.

 This is what I guessed you'd say.

 It can be something extracted from systemd, or something new and
 revived from the old date and time mechanism, but it won't be something
 we support and maintain in gnome-settings-daemon.

 And I'm glad I have 3000 less lines code to maintain.

 I'm just a little bit concerned about how this looks.  I love when we
 can delete code, but we're doing it by disabling a previously-working
 feature for a portion of our users.

 If we introduced new optional features that depended on a particular
 systemd functionality in order to operate, it would be one thing.  We do
 that often.  This change is a regression of existing functionality in
 the name of I don't feel like maintaining it anymore.

 I'd also feel a bit better if I thought you had made efforts to get in
 touch with those that would be affected by this regression.  Ubuntu
 isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for
 the last week I've been trying to convince them that they should.  If I
 had succeeded (which I am now glad I didn't) then this change would have
 been a royal pain, creating a whole lot of new work to fit into an
 already full schedule.

 Many of our own end-users will still want to install GNOME 3.4 onto
 their Ubuntu systems (myself included).  I look forward to the mention
 in our release notes about how they can no longer change their time
 because we wanted to delete a bit of code.

I agree with desrt. I've been actively working to package the parts of
GNOME 3.4 that won't make it into the next Ubuntu release so that
people that want the latest GNOME can have easy access to it via a
PPA.

While writing the extra code that Debian and Ubuntu will need may only
take a day or a few days' work for you, it's probably beyond my
abilities. I was going to make a final request before Ubuntu's feature
freeze for g-c-c/g-s-d 3.4 to be reconsidered since it works except
for some minor work needed in lightdm and unity. That work will have
to be done anyway if we even want g-c-c 3.4 to be made available in
the extra PPA.

Dropping support for Debian  Ubuntu doesn't seem a very friendly
move, and it's only going to delay getting GNOME 3.4 into the hands of
your user base.

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

Re: Features !

[Jeremy Bicha]

On 6 October 2011 08:13, Seif Lotfy s...@lotfy.com wrote:
 The Jump-list stuff has been on my list for a while:
 What we are facing here is:
     Adding actions to the appmenus: new tab (browser), new note (for tomboy
 or gnote) or pause (for the media players)
     Adding document shortcuts in the appmenus: 4 most recent documents and
 other most used (in the last x days) documents with gedit

Personally, I think it would be a good idea if the GNOME jumplists and
the Unity jumplists shared the same implementation so that app
developers could have the extra functionality for both platforms and
only have to do the work once. There may be some design issues and
this is probably equally a request to the Ubuntu developers (several
of whom do read this list) as it is the GNOME ones, but I think
crossplatform interoperability is a good thing to aim for.

GNOME's implementation is very young; I have a hard time finding apps
on my computer using this feature even in GNOME 3.2; Unity has more
apps using jumplists.

Jeremy Bicha
___
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)

[Jeremy Bicha]

On 19 September 2011 17:08, Felipe Contreras felipe.contre...@gmail.com wrote:
 On Mon, Sep 19, 2011 at 11:05 PM, Ionut Biru io...@archlinux.ro wrote:
 I didn't participate to this discussion before but i think the survey is
 pointless now because GNOME 3 wasn't presented to users at all.

 From the top 10 mainstream distributions, conform distrowatch, only 2 of
 them have gnome 3.0.

 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.

I agree with Ionut. For big distros, GNOME 3 has only been officially
released on Fedora  Arch. If you want to get the opinions of normal
users, it would be better to wait a few more months to pick up
OpenSUSE, Ubuntu, maybe even Debian unstable, and Fedora 16 (of course
Fedora 15 had GNOME 3 too), etc.

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

Empty Power panel in System Settings

[Jeremy Bicha]

I had a bug this week where the power was screwy and GNOME briefly
thought my laptop was a desktop. I was awfully surprised to see that
the Power panel in System Settings 3.2 has only one item Suspend when
inactive for This looks really bad. I'm not certain that
autoresizing the window is a great idea but a huge empty space isn't
good either, but resizing from taking up half the screen on my laptop
down to an All Settings button and one option just doesn't feel right.
GNOME's getting criticism for cutting out options and this design
seems to be accenting the emptiness of what's left after possibly too
much pruning.

There are 20 items in System Settings now, which might be recreating
some of the trouble with the old gnome-control-center. I still get
confused on the difference between Displays, Power, and Screen and
I've been using GNOME for years. I think there is a whole lot of
overlap between Power and Screen.

As others have said, I wish design had its own mailing list where I
could ask questions like this  not spam the whole developer list. I
don't think opening a bug is a good idea when the solution isn't clear
and using IRC for decision making (especially without IRC logs)
excludes those who can't participate in real time during the
European/American workday.

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

Re: Empty Power panel in System Settings

[Jeremy Bicha]

On 11 September 2011 23:58, Matthias Clasen matthias.cla...@gmail.com wrote:
 On Sun, Sep 11, 2011 at 10:21 PM, Jeremy Bicha jbi...@ubuntu.com wrote:
 I had a bug this week where the power was screwy and GNOME briefly
 thought my laptop was a desktop. I was awfully surprised to see that
 the Power panel in System Settings 3.2 has only one item Suspend when
 inactive for This looks really bad.

 Sounds like a bug. Why don't you just file it ? That would be more
 productive than this extended hand-wringing about the number of
 options and the number of communication channels to the design team...

Thanks, I submitted https://bugzilla.gnome.org/show_bug.cgi?id=658780
. I hesitated just filing the bug at the beginning as I wasn't sure
what the best answer should be, but writing my thoughts helped me
think through it.

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

Re: Launching an application requires too many mouse clicks in Gnome 3

[Jeremy Bicha]

On 4 September 2011 01:43, Xavier Cho fender_ru...@yahoo.co.kr wrote:
 Most of all, I think Gnome 3 requires too much user interaction when
 navigating in the program menu. In the days of global application menu, when
 you need to launch an application all you need to do was 1) click on the
 panel menu icon, 2) and navigate by hovering your mouse over the categories,
 3) then click on the application. All it needed was 2 clicks and minimal
 mouse movement.
 However in Gnome 3, you need first 1) move your mouse to the upper left
 corner of the screen, 2) and click on the programs menu, 3) wait couple of
 seconds (especially when you click it for the first time), 4) move your
 mouse to the opposite end of the screen to click through the application
 categories, 5) and again move your mouse pointer to where the application
 is, 6) and finally click on the icon to launch it.
 In summary, now it requires 3 + number of categories clicks and much more
 mouse traversal to lauch an application, which I feel a setback in terms of
 user experience compared to Gnome 12.

Devil's advocate. It is possible to launch apps without any mouse
clicks. Press the Windows key (or whatever you like to call the thing)
to open Activities. Type a few letters, (optionally use the arrow
keys), and press Enter to launch the app.

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

Re: Where is the data?

[Jeremy Bicha]

On 19 August 2011 19:00, Giovanni Campagna scampa.giova...@gmail.com wrote:
 As a specific example of unscientific user testing, I got a friend of
 mine to try GNOME 3 at the desktop summit, and when it was time to
 shutdown he just asked me, because he found no way and he thought it was
 a bug. I'm sorry but I didn't have any explanations, so I just said the
 designers said so, and similarly I had none when some KDE hackers asked
 me on the same problem.
 I know that what I write, following the guidelines and the mockups, is
 right. But people providing feedback don't always agree with that, and
 if myself cannot understand the reason, how can I explain to them?
 I understand that some features in 3.0 were like design experiments,
 because we have the whole 3.* cycle to improve. But if the results of
 those experiments (that is, people's feedback) is not analyzed
 thoroughly, how can we be sure that the design is right? Or on the other
 hand, how can I see that the feedback is listened to, if decisions are
 never reverted?

The Alt modifier to get to Shutdown options in the usermenu is clearly
wrong. As far as I can see, that Alt modifier is used only once in the
entirety of GNOME Core and is definitely not a common interaction
anywhere in the software world. Thus it is completely
non-discoverable. It is impossible for anyone to ever figure out that
functionality unless they were told it was there. Core functionality
like powering off a computer should not be an easter egg.

I know that this has been discussed at length on the bug report and
elsewhere but the designers have so far refused to revert this
bug/feature so that normal people can use the usermenu effectively. I
believe Debian has interest in shipping a non-hidden Power Off button
and I'd expect Ubuntu's GNOME Shell package would follow that example.

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

[Jeremy Bicha]

On 28 July 2011 08:51, Thomas Lübking thomas.luebk...@gmail.com wrote:
 I thought that was what the GenericName entry was supposed to be good
 for, so gnome-terminal.desktop would have

 Name=GNOME Terminal
 GenericName=Terminal
 Exec=gnome-terminal

 and the runner/menu could use the GenericName unless there's a
 clash (cause konsole's GenericName is Terminal as well) where it
 could fall back to the Name enties for disambiguation.

 So my question regarding all this flood in my inbox would be:

 Does gnome-control-center now use System Settings for
 the GenericName or the Name entry of gnome-control-center so whether
 there's a real issue with disambiguation (as long as you want to avoid
 invoking the Exec string) or just runner/menu xyz is too stupid to
 resolve ambiguities?

Here's what the .desktop files look like:

http://git.gnome.org/browse/gnome-control-center/tree/shell/gnome-control-center.desktop.in.in
https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/annotate/systemsettings/app/systemsettings.desktop

Jeremy Bicha
___
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

[Jeremy Bicha]

On 22 July 2011 17:17, Ben Cooksley bcooks...@kde.org wrote:

 Now lets go into something more productive and perhaps we can fix this
 before the sunny Desktop Summit.

 Hi Olav,

 In terms of being productive surrounding this, I have several questions:

 Screenshots on your live wiki indicate that GNOME developers were
 aware of the use of the System Settings name by KDE. Why did your
 developers deliberately proceed with the use of this name, knowing it
 would cause a conflict? (This was the primary reason why I was
 particularly angry about the discovery of your use of this name)

 Is there any reason why it cannot be renamed once more as soon as is
 possible so that the next release your team makes fixes this issue?

 I would prefer to resolve this issue as soon as possible, to minimise
 the work packagers will inevitably do to block KDE System Settings
 under GNOME, and the resulting KDE application user support issues
 that will arise.

 Regards,
 Ben Cooksley
 KDE System Settings Maintainer

To be more specific about the problem, installing kde-workspace to a
GNOME installation results in 2 indistinguishable apps named System
Settings and 2 named System Monitor. On Ubuntu at least, if I want the
GNOME version, I have to remember to click the first System Monitor
but the second System Setting which is awfully frustrating. Here's a
screenshot from my Ubuntu install:
https://launchpadlibrarian.net/75745040/Gnome%20Shell%20screnshot.png

GNOME happily has the OnlyShowIn:Gnome,Unity key set for
gnome-control-center but KDE is unwilling to do the same because that
is the only way to change important preferences that affect KDE apps
in general.

I'd like to suggest that the GNOME developers consider changing the
public name of their app to System Preferences. This matches the Mac
OS X design and arguably GNOME follows some parts of OS X design.
Furthermore, it is more in line with Gnome 2's SystemPreferences and
SystemAdministration.

I suspect GNOME developers would rather users not install KDE apps,
but that's a narrow viewpoint. As one example, GNOME has no equivalent
to the educational suite that kdeedu provides.

I also don't think GNOME was intentionally malicious in choosing their
app's new name but it is creating an interoperability issue that ought
to be resolved.

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