Re: GNOME 3.38 release schedule

[Florian Müllner]

On Thu, Apr 2, 2020 at 16:35, Michael Catanzaro  
wrote:
On Thu, Apr 2, 2020 at 11:13 pm, Florian Müllner 
 wrote:

Is it just me or are the April 25th releases missing?


Definitely just you... they're in there! Just tested adding it in 
Evolution.


Odd, didn't work for me in Google Calendar.

But hey, good to see there are bugs elsewhere too I guess :-)



This URL should work in GNOME Calendar:

https://www.gnome.org/start/unstable/schedule.ics


That worked indeed, thanks.


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

Re: GNOME 3.38 release schedule

[Florian Müllner]

On Thu, Apr 2, 2020 at 15:51, Michael Catanzaro  
wrote:


There is an ICS file available for your calendar at
webcal://www.gnome.org/start/unstable/schedule.ics.


Is it just me or are the April 25th releases missing?


> We are currently trying to make it work in GNOME Calendar. :)

Yay!

Regards,
Florian


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

Re: A little experiment: GNOME on wayland-only?

[Florian Müllner]

On Sun, Nov 24, 2019 at 7:19 PM Michael Catanzaro  wrote:
>
> On Sun, Nov 24, 2019 at 4:23 pm, Carlos Garnacho 
> wrote:

> > Beyond that, AFAICT if other regular GNOME session services/apps
> > indirectly rely on X11 at build/runtime, it's an oversight.
>
> Well there is libgnomekbd. That seems like the main issue currently, as
> it's required for core desktop functionality

It depends. If the goal is to not use X11 at runtime, then the tool
provided by libgnomekbd is indeed one of the outstanding issues. But
if the goal is a session with no X11 support at all, then two
non-functional menu items in gnome-control-center/shell look tame
compared to mutter's build dependencies IMHO :-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.34 released

[Florian Müllner]

On Fri, Sep 13, 2019 at 3:19 PM Andre Klapper  wrote:
>
> On Fri, 2019-09-13 at 04:56 -0500, Ty Young wrote:
> > Bit of a problem however... A background image that I used was removed
> > in this version and there isn't any fallback logic to reset the
> > background image. Can this maybe be fixed in the first point release so
> > it never happens again please? Pure white desktop backgrounds aren't
> > very pleasant to look at...
>
> Feel free to file a bug report with clear steps to reproduce and
> version information in https://gitlab.gnome.org

I filed https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/722
for the gnome-shell side.

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

Re: Missing releases and state of 3.33.90

[Florian Müllner]

Hi,

On Tue, Aug 13, 2019 at 8:24 PM Olav Vitters  wrote:
>
> Further, gnome-shell 3.33.90 incorporates an gnome-desktop API/ABI (?)
> change, but it doesn't actually check that gnome-desktop is new enough.

That is because gnome-desktop is only required at runtime (via
gobject-introspection) and not at build time.

If it is an issue, we can either
 - add a version check to the build dependency in mutter
 - start to add runtime checks á la
"imports.package.requireSymbol('GnomeDesktop', '3.0',
'BGSlideShow.file');"
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Good read from a new GNOME user

[Florian Müllner]

On Thu, May 2, 2019 at 1:27 PM Allan Day  wrote:
>
> > 4. Unnecessary notifications (e.g., "Application is ready")
>
> Indeed, my feeling is that those notifications do more harm than good.
> I can't see an issue for this; does anyone know of one?

There are several bugs in bugzilla, but IMHO the notification isn't
the actual issue.

The notification is shown when a window "demands attention".

That's something applications may request themselves, for example
after a longer operation finished (a big download, cd burning (the two
people who still do that), ...). It would be wrong to pop up the
window out of nowhere, and simply ignoring the hint doesn't seem right
either. A notification seems very appropriate here, although we'd
rather have applications send them themselves instead of using an old
hint.

The other case (and that's the one we are really talking about) is
mutter setting the hint on a window after focus-stealing-prevention
kicked in. That means that an application tried to focus a window, but
mutter rejected the request because there was some user action after
the event that triggered the focus request. The problem here is that
while not allowing applications to pop up windows randomly - the
canonical example is entering your banking data in a chat window that
pops up - there are cases where focus-stealing-prevention kicks in
when it shouldn't.

Those are the cases where the notification is perceived as annoying
and useless, but removing it isn't an actual solution - it doesn't
mean that the window is shown to the user directly, it means they
don't get any response at all to their action!

The big hammer fix would be to stop doing any focus-stealing
prevention altogether, at the price of having misbehaving applications
interrupt the user at any moment. The better fix would be to find the
cases where we expect focus requests to succeed, analyze why they
don't and address the underlying issue. Which unfortunately isn't
trivial - for notifications for example, we need to get the click
timestamp into GApplication's platform data, then have GTK inject it
into gtk_window_present().
___
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

[Florian Müllner]

On Thu, Apr 25, 2019 at 1:45 PM Carlos Soriano  wrote:
>
>> For making this change properly, I have some questions:
> - Is there a possibility to redirect master to any other name somehow?

Oh, that is a good question. A quick search finds

 $ git symbolic-ref refs/heads/master refs/heads/mainline

If that works for non-local branches (i.e. "origin/master"), then this
would fully address my concern. As long as random
git-tutorials/stackoverflow-answers keep working, we don't end up
adding friction for newcomers and it boils down to us getting used to
a different word. Having made the switch from svn-trunk to git-master
in the past, I'm confident that we can manage that :-)

> - If Git upstream documentation is not updated, can we hold an organization 
> wide change until that happens?
> - Is there some consensus on the word replacement apart of the links Daniel 
> provided? My feeling is that we should wait until there is a common 
> replacement among projects outside of GNOME.

Those question seem secondary to:
 - Is there a broader initiative outside of GNOME to rename master branches?
 - If not, do we want to go on our own (possibly leading the way for others)?

> - Is there a way to "push to the main branch" that doesn't involve a name 
> such as master or mainline?

Not to my knowledge. It's possible to omit the remote name if the
local branch has a remote tracking branch, but I don't know about
anything similar for the main branch. Same for rebase, which IMHO is
more relevant (as gitlab takes care of pushes most of the time).


> Also, I think we should try to come with a name we are all comfortable and 
> use only that one.

+1.

Cheers,
Florian
___
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

[Florian Müllner]

On Thu, Apr 25, 2019 at 1:04 PM Bastien Nocera  wrote:
>
> FWIW, "master copy" has quite a lot of synonyms that are used in other
> languages and can be reused here, such as "copy zero", "original
> (copy)", or in some uses "standard copy".

"Branch zero" has a nice ring to it. (I think it's too cryptic to be
actually used, but gosh does it sound cool!)
___
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

[Florian Müllner]

On Thu, Apr 25, 2019 at 11:58 AM Daniel Playfair Cal
 wrote:
>
> most tutorials do assume that the default branch is called master.

For good reasons: It's used almost universally, so adding an
additional vague "figure out how the main branch is called" step just
adds needless complications.


> That said, if you think about this in terms of a smaller step in a wider 
> change outside of GNOME away from "master", it has the potential to somewhat 
> improve the learning curve.

I somewhat agree, but the "wider change outside of GNOME away from
master" appears rather hypothetical? I'm not aware any broader
initiative to change that convention. If there is, then great, we
should go with the flow. But if the idea is that we change the name
and everyone else will just follow suite, well ... standards
(https://xkcd.com/927/) :-)

But yes, my concerns about the "master" term are not least about
clarity. Besides "master tape" (which is fairly obscure itself), I
mostly associate "master" with skill ("masterpiece", "masters degree",
"Australian Masters" etc.), and that doesn't help with grasping the
meaning of the "master branch" one bit.

If only https://bugzilla.gnome.org/show_bug.cgi?id=171940 was fixed,
we could lobby Linus for a better default ...

Cheers,
Florian
___
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

[Florian Müllner]

On Thu, Apr 25, 2019 at 9:10 AM Carmen Bianca Bakker
 wrote:
>
> Specifically the Git master branch is a bit of a problem. I personally
> think that "trunk" is a much better term, but I do not have _that_ much
> of a problem with the word "master" in this context to do away with
> convention.

I very much agree with this. It's not the greatest term, but there is also value
in conforming with existing conventions, and "master" isn't quite bad
enough(*) to
justify breaking that.

In particular I'm thinking of documentation. git is a complicated
beast with a steep
learning curve. Changing the name of the default branch means we differ from
almost all(**) existing documentation. The change itself may be small, but it
adds some extra friction to an already frustrating learning process.

I know I'll easily adapt to a new name if the project decides to go
ahead with the
change. But it would certainly have been a problem for younger-me, struggling
to get my head around git and following documentation without fully
understanding
what a particular command does in detail ...

Cheers,
Florian

(*) in this context. I'm all for replacing "master"/"slave" references
where we can.

(**) I'm assuming that gitlab's UI picks up the configured name in its
interface,
   and that the people pushing for this change will update the GNOME wiki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Issue running gnome-terminal in jhbuild

[Florian Müllner]

On Fri, Apr 19, 2019 at 11:41 AM Leland Carlye via desktop-devel-list
 wrote:
>
> Hi!. I'm having this issue when building gnome-terminal in jhbuild (jhbuild 
> run gnome-terminal) in Ubuntu
>
> me@ubuntu:~/jhbuild/checkout/gnome-terminal$ jhbuild shell
> me@ubuntu:~/jhbuild/checkout/gnome-terminal$ gnome-terminal
> [...]
> # Error creating terminal: The name org.gnome.Terminal was not provided by 
> any .service files

gnome-terminal uses a client/server split, the latter is activated via
D-Bus. dbus-daemon generally doesn't
know about .service files installed in the jhbuild prefix, so it fails
to find it.

The following workaround should work:
me@ubuntu:~/jhbuild/checkout/gnome-terminal$
$JHBUILD_PREFIX/libexec/gnome-terminal-server & gnome-terminal

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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Fri, Apr 19, 2019 at 11:42 AM Britt Yazel via desktop-devel-list
 wrote:
>
>  I don't like not knowing if Telegram/Discord/Steam are still running after I 
> close them. [...] I'm not sure why exactly these apps don't show a running 
> indicator in the Dash for this use case.

As far as the shell is concerned, an application is running if at
least one window is associated with the app.

That definition isn't easy to change, because there's a fair amount of
technical limitations in place: We have reasonably reliable heuristics
for finding the .desktop file that "belongs" to some window, there's
no such thing for random processes.

There is hope for "non-random" processes though. Flatpak does know
about its running processes and to which app they map, and could
expose that information to the compositor. Maybe a systemd user
instance could provide something like that as well.

It is certainly a question the design team is pondering:

https://wiki.gnome.org/Design/Whiteboards/BackgroundApps


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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi  wrote:
>
> You cut the part where I said the appindicator implementation should be 
> changed. :-)

I thought you were referring to the client library, not the underlying spec :-)

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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 5:36 PM Emmanuele Bassi via desktop-devel-list
 wrote:
>
> If the answer to status icons is to adopt/adapt the appindicator API, I'm 
> also fine with that;

I'm not. The StatusNotifier spec is seriously flawed, and I don't want
to support it unless at least the issues that were raised ten years
ago are addressed (the spec was put up for "review" on xdg-list, but
then any comments were hand-waived away with "if you don't like it,
don't implement it").

Seriously, the spec is so crappy that there are two implementations
that are both compliant, but interpret the spec in different and
incompatible ways (see the implementation-specific handling in [0]).

If we want to support something *like* appindicators, it must be a new
and fixed API[1] that apps can port to, not the existing API, sorry.

Cheers,
Florian

[0] 
https://gitlab.gnome.org/Community/Ubuntu/gnome-shell-extension-appindicator/blob/master/statusNotifierWatcher.js#L137
[1] ideally tying in with the newer org.freedesktop.Application stuff and GMenu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 2:38 PM Alexandre Franke  wrote:
>
> On Sat, Mar 23, 2019 at 7:07 PM Britt Yazel  wrote:
> > I want to re-poen an old argument now that we have seen the effects of
> >
> > An example of this biting us in the arse is that with 3.32
> > TopIcons is causing the CPU usage to run through the roof, and people are
> > blaming the Shell for the CPU usage, not the extension, leaving our users
> > with a bad taste in their mouths.
>
> That is indeed an issue, I acknowledge this. It doesn’t mean the
> premise of this email is correct.

It *can* be an issue.

In this particular case it does look like it was triggered by some
change in mutter/gnome-shell, so the blame isn't misplaced and moving
tray icons back into the shell itself wouldn't fix it.

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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 9:57 AM Allan Day via desktop-devel-list
 wrote:

>> An example of this biting us in the arse is that with 3.32 TopIcons is 
>> causing the CPU usage to run through the roof, and people are blaming the 
>> Shell for the CPU usage, not the extension, leaving our users with a bad 
>> taste in their mouths.
>
>
> Can we can do a better job at sign-posting which extension people should use?

A couple of months ago I said I was willing to maintain an "official"
fork of the extension[0].

Except for the ID the fork should use (I really don't want to use the
private e-mail of the former maintainer), everything is lined up[1],
but unfortunately the name issue is still waiting for a conclusion[2].

Cheers,
Florian

[0] https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/116
[1] https://gitlab.gnome.org/fmuellner/top-icons/tree/import
[2] https://gitlab.gnome.org/Infrastructure/GitLab/issues/367
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Florian Müllner]

With regard to dropping the 'quit' action, is there any guidance for
background applications? That is, apps where closing all windows does
*not* exit the application, but the explicit 'quit' action does.

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

Re: Retiring app menus - planning for 3.32.0

[Florian Müllner]

On Fri, Sep 21, 2018 at 4:00 PM Bastien Nocera  wrote:
>
> On Fri, 2018-09-21 at 12:24 +0100, Allan Day wrote:
> > To be clear, I'm still thinking this through but, if you had a page
> > in
> > the user docs which was a simple table of keyboard shortcuts, which
> > was one click away in the user docs, there wouldn't be all that much
> > to separate it from the keyboard shortcuts windows.
>
> The docs would still show up in a separate application, and you'd be
> mixing writing styles. The user docs are usually more verbose, and the
> keyboard shortcuts are terse.

Also: If a shortcut is changed or added, the shortcuts window will
reflect that for
all users (albeit some bits show up in English until translations catch up). The
user documentation will be outdated until translators pick up the changes.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.29.4 released

[Florian Müllner]

On Sat, Jul 21, 2018 at 3:56 AM Javier Jardón  wrote:
> The list of updated modules and changes is available here:
>
> https://download.gnome.org/core/3.29/3.29.4/NEWS

Looks like something went wrong, that list (and the list of sources)
is full of versions from about a year ago ...

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

Re: Protected branches in GNOME's GitLab

[Florian Müllner]

On Mon, Apr 30, 2018 at 6:30 PM Milan Crha  wrote:

> Does it mean, that an automatically created user in GNOME's GitLab
> instance, basically a complete stranger, receives the Developer
> privilege, even when it's a Reporter (in bugzilla terms)?

No. In the GNOME group, only people with GNOME git access have Developer
privilege (that is, everyone who is allowed to push to git.gnome.org). If
anyone else wants to contribute changes, they have to fork the project in
their personal namespace. As they have full ownership of their fork (Master
privilege), they can push all the changes they want however they see fit
(but without affecting the original upstream repository of course).

Only when they want their changes to be applied back upstream they open a
merge request (from some branch in their forked repository to a branch
(likely master) in the original repo), and someone with Developer privilege
can then review those changes and merge them once they are happy with the
result.


> Which branches are marked as protected in GNOME's GitLab? The master
> branch is probably protected by default. Which are the other branches?

None as far as I know.


> According to [1] I can mark/unmark branches as protected when I'm at
> least the Master level of the project, but doing that each six months
> when branching for stable feels like one more thing to easily forget
> about, thus it would be nice to have some common "mark-as-protected
> gnome-X-YZ branches when created"

You can protect multiple branches with a single rule by using a wildcard,
for example "gnome-*" (to catch all current and future stable branches) or
"gnome-3-*" (to make unintended matches less likely).

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

Oh my. I certainly did not intend to start a rant thread, sorry for that.

To clarify: I am not complaining that RT is taking away my favorite
toy. JHbuild is a great tool when it works, but it still breaks far
too often for newcomers or non-regulars. And as you rightly point out,
this is not fixable unless the build is completely isolated from the
build machine. Having to adjust my workflows is a price I'm happy to
pay if this works as advertised:

On Tue, Jan 23, 2018 at 2:18 PM, Tristan Van Berkom
 wrote:

>On BuildStream
>~~
>BuildStream is a tool which puts determinism of builds first and
>allows absolutely no room for unknown factors contaminating your
>integrated build result.

So thanks for working on that!


I'm also not complaining that RT doesn't want to be responsible for
maintaining the JHbuild moduleset anymore - even if it wouldn't be
additional work (which it is), we shouldn't delude what we consider a
GNOME release by providing two diverging versions of it.


Really, the only thing I disagree with is that RT appears to actively
discourage maintainers from updating JHbuild before everyone actually
has the option to make the switch - sure, if updating GTK+ fails for
me because harfbuzz gained a new dependency, I'll be able to figure
out what that dependency is, what's its upstream is and whether it's
available in reasonably current distros. But it'll be a lot easier and
quicker for whoever made the change in the first place :-)

I know that work is underway to fix the situation for core desktop
components, but in the meantime it would simply be nice if everyone
working on the platform was aware that some components are still stuck
on JHbuild for the time being, so updating it(*) after "breaking"
changes along with gnome-build-meta would be much appreciated.

Cheers,
Florian

(*) to be clear: I'm only concerned about the platform/dependencies
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

On Mon, Jan 22, 2018 at 2:34 PM,   wrote:
>
>
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>>
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that was even
>> possible nowadays.

Very much, I actually use a jhbuild GNOME session as my everyday
system. On a recently current system, a separate gnome-jhbuild.desktop
file in /usr/share/{x,wayland-}sessions with "Exec=jhbuild run
gnome-session" is enough to get a working session. If you want DBus
activated services from your jhbuild prefix to work as expected, the
invocation gets a bit trickier, but it's still possible.


> gnome-shell used to be possible using 'jhbuild build gnome-shell' and
> 'jhbuild run gnome-shell -r', but the last time that worked for me was many
> years ago.

Right, as noted by Bastien, you cannot swap out the display server, so
replacing the running shell only works when it is not acting as one
(i.e. not in the wayland session).


> Even trying different combinations of undocumented args like
> --nested and --wayland, I've yet to see it work in recent times.

That one should still work:
jhbuild run gnome-shell --replace --nested --wayland

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

On Sat, Jan 20, 2018 at 6:06 PM,   wrote:
> When adding or removing a dependency from your
> module, please now update gnome-build-meta instead.

The BuildSteam page still mentions this:
> In case you are trying to develop integrated components such as GNOME Shell,
> GDM, gnome-session or gnome-keyring, these are more difficult and not yet 
> supported.

Is this information outdated? At least I see all those components in
the gnome-build-meta repo, so I dare to hope ...
If not, are we now expected to monitor all our dependencies'
dependencies (and so on) and effectively take over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Florian Müllner]

On Wed, Jan 10, 2018 at 9:10 PM, Robert Ancell  wrote:
> You can also easily set up CI to build on multiple OSs (e.g. Ubuntu and
> Fedora).

But please take into consideration that resources are limited, so
don't block everyone else's pipelines unless there are real
differences that are being tested.
I'd hope that we'll have a neutral "reference GNOME"[0] image before
long that allows us to run tests without creating the impression of
favoring Fedora over Ubuntu or vice-versa.

[0] to avoid the loaded "GNOME OS" term
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Florian Müllner]

On Wed, 13 Dec 2017, 09:36 Carlos Soriano,  wrote:

> The shortcuts for example, would be good to have a shortcuts window as we
> implemented recently at GNOME
>
The problem with those is of course that they are often not very
discoverable themselves. Case in point, GitLab already has that somewhat
hidden behind a '?' shortcut.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Florian Müllner]

On Thu, Dec 7, 2017 at 6:19 PM, Michael Catanzaro  wrote:
> I'll add two more to Milan's list:
>
> (1) Canned replies. I would rather stay with Bugzilla forever than give up
> canned replies.

That is being tracked:
https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/33

There are some links to upstream discussions there, so I'd expect some
comparable functionality in gitlab eventually.


> (2) Still waiting for rebase merge requests. Ditto.

And this actually *has* been considered a blocker the entire time. So
seeing the migration going forward, I suspect that there has been
movement in that area ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla migration tool user accounts

[Florian Müllner]

On Fri, Dec 1, 2017 at 9:43 AM, Carlos Soriano  wrote:
> commenting on behalf of users doesn't seem to be something as bad as I though 
> since
> nobody mentioned that here so far :)

If I understood correctly, rather than handling out temporary admin
tokens to random people (like me), the plan is to have existing gitlab
admins run the migration on the maintainer's behalf. If that's indeed
the case, then I honestly don't see too much difference with the
current setup: Some people in the community have direct access to
bugzilla's underlying database, and we trust them to use that power to
keep the service running and not to impersonate other bugzilla users.
Gitlab offers a more convenient option than raw SQL, but it's not
fundamentally different - we need people who keep our infrastructure
running, and we trust them to not abuse their powers.

Also if I recall correctly, the migration from bugzilla 4 to 5
involved migrating existing data to a new database schema, which means
old comments were copied (aka "commenting on behalf of users") ...

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

Re: gjs 1.51.2

[Florian Müllner]

On Thu, Nov 16, 2017 at 8:40 AM, Carlos Soriano  wrote:
> Yeah, I asked Andrea to do that two weeks ago for every project that moved
> to GitLab, so I wondered what happened.

I don't think the redirect will prevent people from

 - creating bugs via xmlrpc (`git bz file`)

 - reassign bugs from other products to gjs

Cheers,
Florian
___
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

[Florian Müllner]

On Mon, Nov 6, 2017 at 3:23 PM, Mario Torre  wrote:
> On Mon, Nov 6, 2017 at 11:54 AM, Emmanuele Bassi  wrote:
>
>> 2. The user cannot install any other screenshot tool, unless they are
>> also using X11 only, given that there is no unified screenshot
>> interface for Wayland.
>
> This should be fixed though with a proper interface added for all
> environment to use

There is a Screenshot method in org.freedesktop.portal.Desktop that
applications can use (it is targeting the flatpak/portal case, but
there's nothing preventing a non-flatpaked app to call the method). I
don't know the status of backends other than GNOME (for instance I
don't see it in https://github.com/KDE/xdg-desktop-portal-kde), but I
would expect that gap to close eventually.

Cheers,
Florian
___
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

[Florian Müllner]

On Mon, Nov 6, 2017 at 11:26 AM, Carlos Soriano  wrote:
> I actually had no idea about the shortcuts until recently, specifically for
> screenshoting an area, so I would be slightly against this. If we had the
> shorcuts window in GNOME Shell and the initial setup would show it as it's
> planned then I would probably be fine with the removal.

That's an argument for keeping it installed by default (or rather: in
the set of apps we recommend distros to install by default). I agree
that this makes sense, but installed by default is not the same as
unremovable - I don't see why users shouldn't be allowed to uninstall
the screenshot app in Software if they want to.

Cheers,
Florian
___
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

[Florian Müllner]

On Sat, Nov 4, 2017 at 1:03 AM,   wrote:
>  Specifically, I propose that 
> GNOME
>  be removed from the appstream metainfo for all of our apps except the 
> following four:
>
> * gnome-screenshot

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

[Florian Müllner]

Hey,

On Sat, Nov 4, 2017 at 4:44 PM, Andreas Nilsson  wrote:
> Could also be that the actual bug in this case is that she shell should
> not show Weather, World Clocks, etc. if these apps are not installed, or
> not make it a link or something along those lines.

That's indeed supposed to be the case for Weather and Clocks - if they
aren't installed, the corresponding sections should be hidden. In case
of the calendar, the date headings should be insensitive if either no
calendar application has been configured, or the configured app is not
available. So there is a bug here, but it's that for some reason the
code isn't working as expected on your system (or atomic?) ...
___
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

[Florian Müllner]

On Sat, Jun 17, 2017 at 11:29 PM Florian Müllner <fmuell...@gnome.org>
wrote:

> I hope that subscribers to an issue will receive a notification when a
> mentioned issue is closed
>

To answer my own question: It looks like that's not the case, so anyone
interested will need to explicitly subscribe to the related issue. Still,
hardly a deal breaker IMHO.

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

[Florian Müllner]

On Sat, Jun 17, 2017 at 4:48 PM Michael Catanzaro 
wrote:

> I think we had
> some rough consensus on this list that the primary missing enterprise
> feature we need in the open source edition is rebase-style merge
> requests. Was there anything else?
>

It looks like related issues are an EE feature, at least for now:
https://gitlab.com/gitlab-org/gitlab-ce/issues/4058

Although personally this bothers me a lot less than forced merge commits,
assuming that the suggested workaround of using free-form comments ("This
depends on the stuff in #12345") works well enough. I hope that subscribers
to an issue will receive a notification when a mentioned issue is closed,
but if not and I'll have to manually subscribe to related issues where
necessary, then that's an annoyance I can live with ...

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

[Florian Müllner]

On Fri, May 19, 2017 at 9:55 PM Shaun McCance  wrote:

> I don't disagree with anything you're saying. As long as there's an
> easy way to get a list of issues with a specific label across all
> projects (and projects in different groups?), then we'll figure it out.
> And if there's not, we'll figure it out another way.


It looks like labels can be defined by either the project or the group:

https://gitlab.gnome.org/groups/GNOME/issues?label_name[]=newcomers

So as long as all the canonical GNOME repos are under that umbrella, it
should work just fine.
___
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

[Florian Müllner]

On Wed, May 17, 2017 at 4:08 PM Mathieu Bridon  wrote:

> On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote:
> > > No, as written in the wiki you write "Closes: $number" and it will
> > > handle things automatically.
> > > Of course some addition could be done to do the rewrite.
> >
> > Right, so that's not automated, and you can't know what to put in the
> > commit messages until you've create the merge request. Kind of a
> > chicken and egg problem.
>
> The merge request gets automatically closed when you merge it.
>
> The "Closes #number" is to associate the commit to the corresponding
> issue (and have it closed automatically), not the pull request.
>

Can we please have the full issue URL there, either by convention (as we do
now) or enforced by the tooling? In the best case, the raw number is
inconvenient when looking up the issue from the commit (outside the web
UI): "Select+copy number, switch to browser, go to gitlab.gnome.org, paste
number" vs. "click a link". In the worst case it's confusing, because it is
unclear what the number refers to - for example the github mirror will
likely turn them into links to non-existent issues on github, and if we
ever decide to migrate to something else in the future, you need to know
which issue tracker was used at the time of the commit.


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

[Florian Müllner]

On Wed, May 17, 2017 at 2:20 PM Jehan Pagès 
wrote:

> On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera  wrote:
> > I don't like the fact that the bug report and the merge request are
> > separate.
>
> I don't like this either. This just makes no sense.
>

While I tend to agree, I do see a use case for the separation - multiple
pull requests for a single issue, if a fix involves changes to multiple
products.

We currently often avoid the overhead of cloning the issue, and just attach
all patches in the same report (say, a gsettings-desktop-schemas patch and
the settings consumer, mutter/gnome-shell). That assumes that whoever
applies the patches knows where the different bits go, and linkified commit
hashes get messed up for non-matching products.

That said, going from a attached-patches-only workflow to a
branches+pull-requests-only workflow looks like swapping a toolbox full of
hammers for a toolbox full of screwdrivers - the current workflow gets
awkward with bigger patch sets, while pull requests add overhead that's
fairly pointless when dealing with just a couple of patches (most issues
really) ...


Florian

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

Re: I have realised the problem here

[Florian Müllner]

On Tue, May 2, 2017 at 11:28 PM Diego Fernandez 
wrote:

> However, there's a simple solution:
> https://extensions.gnome.org/extension/15/alternatetab/
>

Or simpler:
$ gsettings set org.gnome.desktop.wm.keybindings switch-applications "[]"
$ gsettings set org.gnome.desktop.wm.keybindings switch-windows
 "['Tab']"

The extension really just exists to have a different Alt+Tab default in
GNOME Classic, all the actual functionality is implemented in gnome-shell
itself.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-settings-daemon now split up

[Florian Müllner]

On Tue, Oct 11, 2016 at 11:25 AM, Bastien Nocera  wrote:
>The GNOME Classic session file has not been updated yet

It has been updated on master now.
___
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

[Florian Müllner]

On Tue, May 31, 2016 at 6:47 PM Michael Catanzaro 
wrote:

> Just please wait a couple days first to see if there are any
> substantial objections (which I do not expect).


Is this really necessary? This is a revived thread from February, so surely
there has been plenty of time to voice objections ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: RFC: GSound, a GObject library for playing system sounds

[Florian Müllner]

On Thu, Dec 4, 2014 at 12:25 PM, Richard Hughes hughsi...@gmail.com wrote:
 Surely by pushing all your awesome code into GDK or GTK we would get all this 
 awesome new
 functionality for free in the toolkit?

Or possibly GIO? Playing sounds is not really tied to a (visible) UI,
though linking to libcanberra would bring in a couple of dependencies
which might be undesirable in the GIO case ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: session-manager fails to recognize inhibitor

[Florian Müllner]

On Sun, Oct 5, 2014 at 9:50 PM, Jan Niggemann j...@hz6.de wrote:
 My problem is that the inhibition and the reason are not shown during log
 out on GNOME 3.4 (Debian stable 32bit). Why is that?

Most likely because your console application does not have access to
the same session bus used by gnome-session. If you are using systemd,
you could run your backup program with systemd-inhibit, otherwise I
can't think of anything better off-hand than to split the task into
two components (the actual script, and a service running in the user
session which inhibits shutdown when the former is running) ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Problems to compile gnome-shell - st-texture-cache.c

[Florian Müllner]

On Sun, Sep 7, 2014 at 10:12 PM, Mauro Alexandre upma...@gmail.com wrote:
 I can't compile gnome-shell because GTK_ICON_LOOKUP_DIR_RTL and
 GTK_ICON_LOOKUP_DIR_LTR is undeclared in file src/st/st-texture-cache.c.

You need to update GTK+ - those two flags first appeared in 3.13.2, so
that's the minimum version you need to build the latest development
release of gnome-shell. If you are building gnome-shell for yourself
(rather than a distribution package), I strongly recommend using
jhbuild[0] to handle dependencies for you (without affecting your
installed system).

-- Florian

[0] https://wiki.gnome.org/Projects/GnomeShell#Building
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dragging windows to resize them to half the screen

[Florian Müllner]

On 27 Jun 2014 11:57, Petko Ditchev pditc...@gmail.com wrote:

 Previously I could drag a window to the side to resize it to the right or
left half. Is it a bug that it's not working with the latest releases?

It is working as expected here (so no, the feature has not been removed,
nor are there any plans to do so) - are you sure that the window you want
to tile allows resizing and can be made smaller than half the screen width?
Also note that there's a setting to disable the feature - if you type
altf2 and run lg, does entering Meta.prefs_get_edge_tiling() into the
dropdown console return true?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dragging windows to resize them to half the screen

[Florian Müllner]

On Fri, Jun 27, 2014 at 12:57 PM, Petko Ditchev pditc...@gmail.com wrote:
 It returns false.

Good, so that's the problem.


 How do I change the setting ?

It depends on whether you are using the normal or classic session, still

  gsettings reset org.gnome.shell.overrides edge-tiling
  gsettings reset org.gnome.shell.extensions.classic-overrides edge-tiling

should take care of both.


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

Re: Power switch to actually turn off my computer

[Florian Müllner]

On Thu, Apr 10, 2014 at 11:51 AM, Charles T. Smith
cts.private.ya...@gmail.com wrote:
 Charles T. Smith cts.private.yahoo at gmail.com writes:

 I've spent an hour or so looking around /usr/lib/python/site-packages/gtweak
 and haven't found what it does yet...

'grep' is your friend - it modifies
org.gnome.settings-daemon.plugins.power button-power.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Power switch to actually turn off my computer

[Florian Müllner]

On Thu, Apr 10, 2014 at 1:01 PM, Charles T. Smith
cts.private.ya...@gmail.com wrote:
 The problem is, I'm new to this group (but I like it!) and I don't know
 where to find org.gnome.settings-daemon.plugins.power - I mean, somewhere
 where I can grep it.

I used git-grep in the gnome-tweak-tool source tree, but a simple

  grep -R 'Power Button Action' /usr/lib/python2.7/site-packages/gtweak

should work as well.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Power switch to actually turn off my computer

[Florian Müllner]

On Thu, Apr 10, 2014 at 2:34 PM, Charles T. Smith
cts.private.ya...@gmail.com wrote:
 Do you suppose that kde also manages the power switch internally?

If by manage the power switch internally you mean call out to
logind via DBus, then yes, I would KDE expect to do the same
eventually (provided that they do offer an option for handling the
power key).
If you are not using GNOME (or more specifically:
gnome-settings-daemon), you should be able to set the desired action
in /etc/systemd/logind.conf(5), via the HandlePowerKey action.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Power switch to actually turn off my computer

[Florian Müllner]

On Thu, Apr 10, 2014 at 5:33 PM, Charles T. Smith
cts.private.ya...@gmail.com wrote:
 So, one responder supposed that gnome listens to the power switch, and
 another responder supposed that logind listens to the power switch - but
 that's only when someone is logged in.

Actually both are correct :-)

On systemd systems, logind handles the power key.
gnome-settings-daemon's media-keys plugin will request an inhibitor
for 'handle-power-key', which means that it asks logind to take over
the handling of the power key. When handling the power key,
gnome-settings-daemon delegates back to logind, but requesting the
action configured by the button-power key in
org.gnome.settings-daemon.plugins.power instead of the one in
logind.conf.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Suggestions for an official GNOME hosted document collaboration suite?

[Florian Müllner]

On Fri, Feb 14, 2014 at 10:27 PM, alex diavatis
alexis.diava...@gmail.com wrote:
 there is any legal issue that prevent gnome to introduce a per-user revenue
 model, or in other words commercial services over open source solutions?

Being a non-profit organization[0], I would assume so (but then I am
not a lawyer).

[0] http://en.wikipedia.org/wiki/501%28c%29_organization
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for a new default window resize behaviour

[Florian Müllner]

On Nov 7, 2013 2:06 PM, Petko Ditchev pditc...@gmail.com wrote:
 drag the window to a corner - it resizes to the adjacent quadrant of the
screen ;

See https://bugzilla.gnome.org/show_bug.cgi?id=696130 for a related
proposal.

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

Re: 3.12 feature: polari

[Florian Müllner]

On Fri, Oct 4, 2013 at 3:33 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Do you have something like a roadmap for what you hope to have in 3.12 ?

I have just added one at https://wiki.gnome.org/Apps/Polari/Roadmap;
there is only one item that isn't either small or doesn't have some
initial code, so it should be quite doable in the 3.12 timeframe.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

3.12 feature: polari

[Florian Müllner]

Polari is a simple IRC client designed for GNOME 3. Tentative designs
have been around for a while, but hacking only started around Guadec.
It is obviously not end-user ready at that point, but I'm confident
that it can be in time for 3.12, thus this feature proposal.

See https://wiki.gnome.org/ThreePointEleven/Features/Polari for more
information.


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

Re: New GnomeGoal proposal: InstalledTests

[Florian Müllner]

On Fri, Apr 26, 2013 at 9:44 PM, Colin Walters walt...@verbum.org wrote:
 Anyways...dropping tarballs is not going to happen soon, but I'm happy
 to consider what we need to do to lay the foundations now.

More short-term, would it make sense to leverage the build servers to
run make distcheck when a new tag is pushed and take care of uploading
the generated tarballs?
(Though there's some temptation for maintainers to be lazy and create
a tag without making sure that distcheck actually passes ...)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feature proposal: combined system status menu

[Florian Müllner]

On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon pionchon@gmail.com wrote:
 The main point is that so-called controversial features does not have to
 be either a hard default, either rotting in a branch. They can be shipped as
 default, but with a way to revert them in the case they block the user.

Wait - are you suggesting to create a fork each time a controversial
change is made? How does that scale?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feature proposal: combined system status menu

[Florian Müllner]

On Wed, Apr 24, 2013 at 3:51 AM, Sriram Ramkrishna s...@ramkrishna.me wrote:
 At least until we get a better testing infrastructure in place, the
 only way to get at least *some* user testing is [...] to get some minimal
 exposure to adventurous users of unstable/experimental distributions

 Again treating your user base as your user test bed is going to create some
 backlash.  They have signed on to doing things the GNOME 3 way,  don't abuse
 them by rapidly adding new methodologies that they have to get used to after
 establishing use patterns already.

I was explicitly referring to the part of the user base that
runs/tests development versions. Is treating voluntary testers as test
bed really that bad (abuse even)?


 real users generally only get to test a new feature once it appears in 
 their distro

 I don't agree here at all.  First all, we should be able to use ostree and
 create new images based on the next-gen features branch.  [...]

 Our infrastructure is becoming sophisticated.  Use it and stress it.  We
 didn't get all this hardware for nothing.  Andrea and I will try to help out
 here.

First: If we are actually ready to roll out ostree images, that's
awesome news! Not having to rely on other parties to get our code
tested is a huge step forward. Still, the process is still new, so I'm
a bit wary about overwhelming testers with too many images at once -
getting early feedback on features (this proposal is not the only UI
change I expect this cycle) is certainly worthy, but it should also
not take away too many resources from getting as much testing as
possible of the master branch (after all, that's what we *will* ship
to users - catching regressions from non-UI code churn is not as shiny
as evaluating UI changes, but not any less needed).


Slightly off-topic, I guess that part of my problem is actually that I
don't consider this a huge change - or rather, not anymore. I've first
learned about the rough idea in a casual chat at fosdem, and my first
reaction was certainly along the lines of whoa, big change, not so
sure, ..., but after digesting it for a while, it appears much more
minor. In general, stuff gets moved rather than removed -
tongue-in-cheek, the only thing missing from the mockups are my
neighbors' APs; I know that's not entirely true, and I don't agree on
every detail of the proposal myself (not to mention some question
marks), but I don't doubt that there will be sufficient clarification
and refinement - in particular now when can finally leverage ostree.
I'd just much prefer focusing on discussing/addressing individual
quirks instead of looking for ways to block the change as a whole ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feature proposal: combined system status menu

[Florian Müllner]

On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
ma...@scannadinari.co.uk wrote:
 In fact, I think that these sorts of subtle
 design-based decisions should be held in something like loomio (see
 recent loomio post in desktop-devel), to be later implemented if the
 response is positive.

And as has been mentioned on that thread, this is design by
committee, which is not how it works (or should work). Yes, sometimes
controversial changes are reversed at a later point, and a user vote
would almost certainly have prevented the controversial change in the
first place, but it would also prevent those controversial changes
that turned out right - in particular, neither GNOME 2 nor GNOME 3
would have happened in the first place.


 I think your suggestion of a feature branch can be a worthy compromise, 
 though.

Except that Bastien is right - while on a branch, a feature will
hardly be tested by anyone than other core developers of the same
module. It's unfortunate, but real users generally only get to test
a new feature once it appears in their distro (read: some time after
the feature appears in a stable GNOME release).

So a branch would either
 - be a polite way of rejecting a feature outright - as it doesn't get
any user testing, it is never
   considered ready and punted from release to release
 - land late in the cycle when the few users (read: gnome-shell
hackers) that have tested it
   consider it good enough to let loose on unsuspecting users

At least until we get a better testing infrastructure in place, the
only way to get at least *some* user testing is including it in a
development release as early as possible (but only after being
relatively sure that it won't kill any kittens) to get some minimal
exposure to adventurous users of unstable/experimental distributions
(and fellow gnomies running jhbuild sessions of course). It's far from
ideal, but in contrast to artificially holding back the feature, we'd
get at least some feedback (and a fair chance to address issues before
it hits a stable release).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feature proposal: combined system status menu

[Florian Müllner]

On Mon, Apr 22, 2013 at 8:10 PM, Sriram Ramkrishna s...@ramkrishna.me wrote:
 This is problematic is for those of us who use VPN

The mockup[0] linked from the proposal shows VPN(s) directly in the
menu when a VPN has been set up. Non-issue?


[0] 
https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/combined-system-status-menu.png
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: The name of applications on GNOME 3.7.92 testing image

[Florian Müllner]

On Fri, Mar 22, 2013 at 8:12 PM, Mike mikeandm...@gmail.com wrote:
 I agree with the fact that we need a simpler text editor, but let's
 just call it as Textpad or something... without excluding gedit.

Nobody is excluding gedit. The gedit developers *want* their project
to be called gedit rather than Text Editor [0]. The fact that some
distributions disrespect that wish and rebrand gedit downstream is not
enough of a reason to pick a weaker name for a different[1] upstream
project in my opinion.


[0] https://bugzilla.gnome.org/show_bug.cgi?id=153995 is fairly old,
but the response to more recent attempts to rebrand gedit has been the
same as far as I know
[1] I'm explicitly not saying competing - as Jasper has pointed out,
the target audience is quite different
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Why does killing GS with SIGHUP crash on the 2nd time?

[Florian Müllner]

On Mon, Mar 4, 2013 at 7:16 PM, Marco Scannadinari
ma...@scannadinari.co.uk wrote:
 How can I pass global.reexec_self() to org.gnome.Shell? Sorry, I have
 little to no (g)dbus experience.

Ignoring any error handling:

from gi.repository import Gio, GLib

proxy = Gio.DBusProxy.new_for_bus_sync(
Gio.BusType.SESSION,
Gio.DBusProxyFlags.NONE,
None,
'org.gnome.Shell',
'/org/gnome/Shell',
'org.gnome.Shell',
None);
proxy.Eval('(s)', 'global.reexec_self();')
___
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

[Florian Müllner]

On Mar 5, 2013 5:57 AM, Matthias Clasen matthias.cla...@gmail.com wrote:
 694771  mutter  menus broken in 3.7.10

This was fixed in 3.7.91, somehow we missed closing the bug.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Why does killing GS with SIGHUP crash on the 2nd time?

[Florian Müllner]

On Sun, Mar 3, 2013 at 11:33 PM, Marco Scannadinari
ma...@scannadinari.co.uk wrote:
 For some reason, using this command twice crashes the shell. It is not
 python-specific, as pkill -HUP gnome-shell and killall -HUP gnome-shell
 produce the same result, which is odd because Alt+F2 + r * (a lot)
 does not crash it.

gnome-session will give up trying to respawn the shell if it crashes
too often (where crash means exit with a non-zero exit value). I
don't know where the idea that SIGHUP would restart the shell came
from, it doesn't - the default behavior of SIGHUP is to terminate the
process (e.g. you could just as well use SIGTERM or even SIGKILL, see
man(7) signal). This is different from issuing the restart command
in the run dialog, which will actually restart the shell (instead of
killing the process and relying on gnome-session to spawn another
instance).


 Should I be issuing a different signal to gnome-shell, or do I have to
 use gnome-shell --replace from the commandline?

Any concerns that killing/reloading the desktop interface isn't what
an application should do in my opinion aside, the shell exposes an
Eval() DBus method on org.gnome.Shell, passing global.reexec_self()
will trigger a proper restart.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome shell is really awesome

[Florian Müllner]

On Feb 7, 2013 11:11 PM, Lanoxx lan...@gmx.net wrote:
 Nice post, I am currious about the implementation details of the Classic
 mode.

You can think of classic mode as a gnome-shell session with a default set
of enabled extensions.

 * Is it possible to remove the application menu and then call it with
 the hot key ALT+F1 like in the current fallback mode?

Not directly, though I can imagine a (hackish) extension hiding. The answer
to everything else is no.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fallback mode is going away - what now ?

[Florian Müllner]

On Fri, Nov 23, 2012 at 5:59 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Fri, Nov 23, 2012 at 4:04 AM, Allan Day allanp...@gmail.com wrote:
 A separate user session would be the best user experience, IMO.

 If you think so, we'll have to discuss the technicalities of making that work.

Thinking a bit about this, we can probably add a little session-mode
hook to load extensions in addition to the ones configured in
GSettings, so running gnome-shell --mode=fallback (or classic if we
must) would start with the appropriate extensions (including a simple
one that overrides the location of the button-layout setting to
include the minimize button in the default).

But is this really what we want? Separate sessions strongly indicate
that we provide two different but equal user experiences, rather than
a variation of the default experience which throws in some familiar
bits to make the transition less painful. Or am I misunderstanding
something and we indeed intend to provide the former?


 The Tweak Tool shouldn't have anything to do with extensions. They are
 something that you install and run as a part of the system, not
 something to be tweaked via settings.

While I agree with you that gnome-tweak-tool (and package managers
(*)) are not the right place for extension management, I don't think
this is much of a concern with the matter at hand - as I understand
it, extensions are merely an implementation detail here and not
exposed to the user (except that they should also appear separately on
extensions.gnome.org, so users don't have to switch their system over
entirely if they only care about one or two tweaks). As mentioned
briefly above, I'd still assume an implementation based on extensions
even if we are going for a separate session.


Florian

(*) not to mention an extension management extension - I wish I was kidding
___
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

[Florian Müllner]

On Thu, Nov 15, 2012 at 4:48 PM, Henrique Ferreiro 
henrique.ferre...@gmail.com wrote:

 Users are usually going to install languages they know.


... on distributions that package language support separately. However it
is not uncommon to ship all available languages for an application within
the main package.


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

Re: Removing fallback support code

[Florian Müllner]

On Mon, Nov 12, 2012 at 3:35 PM, Bastien Nocera had...@hadess.net wrote:

 There's also a lot more work (in addition to using XI2 for events
 capture) that would need to be done if we were to remove all the key
 capture from gnome-settings-daemon, namely the hacks Rui has been adding
 for layout switching using modifier keys.

 So it's not as cut'n'dry as you make it sound. Let's discuss this on the
 bugs anyway.


I don't know if we care, but this will also regress in setups using
multiple screens, as mutter is bound to a single screen.


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

[Florian Müllner]

On Fri, Oct 19, 2012 at 3:48 PM, Bastien Nocera had...@hadess.net wrote:
 On Fri, 2012-10-19 at 15:30 +0200, Florian Max wrote:
 On vie, 2012-10-19 at 14:55 +0200, Bastien Nocera wrote:
 On Fri, 2012-10-19 at 08:49 -0400, Matthias Clasen wrote:
   On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net 
   wrote:
Note that I also intend on dropping session tracking support from
ConsoleKit.

That sounds to me like we won't be able to keep using the current CK
path for session tracking - I'm most certainly against reimplementing
removed CK bits in gnome-shell.


 I would recommend that gnome-shell uses systemd to suspend

Yeah, we should probably do that - filed as bug 686482.


 and I would recommend gnome-shell, gnome-session and gdm also drop their 
 ConsoleKit
 session tracking code.
 At the end of the day, the decisions are not mine to make, so if the costs of 
 keeping
 those options are low enough for you, then feel free to keep them.

Well, it doesn't make much sense to run gnome-shell without
gnome-settings-daemon. So if you change the latter to require either
systemd or a dbus-compatible implementation, native CK support in the
shell won't be too useful - in that sense, it *is* your decision :-)

Note that I'm not complaining (I'm pretty sure the CK path is mostly
untested nowadays until it reaches end users), just saying that I
don't think we can consider g-s-d separately - a change like this will
have implications for other modules as well.


Regards,
Florian
___
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

[Florian Müllner]

On vie, 2012-10-19 at 12:19 -0400, Colin Walters wrote:
The other thing we can do (and really should do) is share more code
 relating to systemd/CK and in general system abstractions.

 It's really pretty silly how hard we make it to share code between
 gnome-settings-daemon and gnome-shell.  I'd be happy to move
 more stuff into to gnome-desktop personally.

+1.

And gnome-session has yet another systemd/CK abstraction.

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

[Florian Müllner]

On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 This is what I feel. DBus is our system abstraction layer. I feel that
 making ConsoleKit support the logind interface wouldn't be that big of
 a patch and solve this issue, at least.

Unless I'm mistaken ConsoleKit only provides a subset of logind's
functionality though.


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

Re: Enable accessibility team to automatically receive bugmail on a11y bug reports

[Florian Müllner]

On Aug 16, 2012 1:41 PM, Piñeiro apinhe...@igalia.com wrote:

 On 08/10/2012 07:15 PM, Andre Klapper wrote:

  Still I haven't seen any feedback from module maintainers in this
  thread, and whether an Accessibility component in Bugzilla would be
  accepted. Feedback welcome.

 Being minimalistic we can start with:
   [...]
   * gnome-shell

Certainly no objections from my side.

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

Re: Compiling glib applications

[Florian Müllner]

On Aug 10, 2012 9:38 AM, Lanoxx lan...@gmx.net wrote:
 On 09/08/12 23:13, Colin Walters wrote:
 Patches?? On the desktop *development* list?  What's going on???

 Whats wrong with that, and where should I send it instead?

Nothing. I'm pretty sure Colin was referring to desktop-devel-list tending
to be a place for flame wars rather than productive work - patches are good
:-)

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

Re: Again: please clarify the decision on IBus integration

[Florian Müllner]

On Jul 9, 2012 4:52 PM, Rui Tiago Cação Matos tiagoma...@gmail.com
wrote:
 If you start offloading keybindings and other
 configurations then how do you make sure that the UI will be
 consistent with the remaining GNOME UI?

Particularly for keybindings it's not merely about UI consistency -
parallel keybindings configuration means the responsibility for resolving
conflicting settings is left entirely to users (and of course they'll need
to figure out first that this is the reason for stuff not working as
expected)

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

Re: Be respectful and considerate. A complaint.

[Florian Müllner]

On Jul 2, 2012 11:52 PM, Jasper St. Pierre jstpie...@mecheye.net wrote:
 This has been a part of GNOME since 3.2.

3.0 actually.

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

Re: Finding and debugging the battery applet in GNOME 3.4 fallback mode

[Florian Müllner]

On Tue, May 29, 2012 at 11:47 PM, Martin Langhoff martin.langh...@gmail.com
 wrote:

 I am trying to characterize a bug in OLPC's development builds (based
 on F17) where the battery icon applet is out of sync with upower.

 Where is it controlled from? Under gnome-shell, it is
 /usr/share/gnome-shell/js/ui/status/power.js , but I've failed to find
 the fallback equivalent.


It's in gnome-settings-daemon, see
http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c


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

Re: Finding and debugging the battery applet in GNOME 3.4 fallback mode

[Florian Müllner]

On May 30, 2012 12:28 AM, Michael Biebl mbiebl
mbi...@gmail.com@mbi...@gmail.com
gmail.com mbi...@gmail.com wrote:
 We've had similar bug reports in Debian:
 http:// http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429
bugs.debian.org
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429/http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429
cgi 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429-bin/http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429
bugreport.cgi http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429
?bug=674429 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429

 Not sure if this particular issue has already been reported upstream.

Those are apparently different issues (shell vs fallback). There were some
changes to the private dbus API used between gnome-shell and
gnome-settings-daemon in the 3.4 cycle, which means you cannot mix g-s-d
3.2.x and g-s 3.4.x, which seems to be what you are doing. If you insist on
leaving g-s-d at a version that does not match the rest of GNOME, you'll
have to fix it downstream (it might actually be as easy as reverting commit
8bcbf3030 for gnome-shell).

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

Re: Some points about IM integration

[Florian Müllner]

On Tue, May 15, 2012 at 10:40 AM, Marguerite Su i...@marguerite.su wrote:

 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
  GNOME doesn't want to work well just for tweakers and enthusiasts - it's
  very important to the project that GNOME works well for all users without
  tweaking. We want to give the choice of using Free Software to
  everybody - this is a much more fundamental form of choice than giving a
 small
  group of users the ability to swap out a different input method framework
  underneath GNOME.

 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want.



Please, no reason to get offended - assume well and everything. I'm sure
what Owen meant is the following:

The group of CJK users who tweak / replace the IM (because the
out-of-the-box experience sucks) is small compared to the group of CJK
users who don't use free software / GNOME at all (because the
out-of-the-box experience sucks).

Introducing another level of abstraction (IM framework framework) may
make the first group happy, but it doesn't help the second group at all.
Making the out-off-the-box experience not suck on the other hand should
benefit *all* CJK users.


so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.


Well, according to your own words, GNOME does not ship what [CJK users]
want - I guess you can call that second class. The whole idea of
integrating IM into the core desktop rather than keeping it as an
after-thought is to make CJK users *first* class citizens. So again, please
don't feel offended.


Regards,
Florian
___
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

[Florian Müllner]

On Mon, May 7, 2012 at 1:28 PM, Allan Day allanp...@gmail.com wrote:

 On Mon, May 7, 2012 at 7:15 AM, Andrew Cowie
  Is there a reference application doing this right?

 There are two paths available to applications - (1) replace the menu
 bar entirely, or (2) move some items to the app menu. For (1), the
 calculator [1] is a good example. For (2), I'd recommend checking out
 Nautilus [2].


For [2] there are actually two paths as well:
  a) keep the existing menus, but add an additional application menu; the
tricky part is to make sure
  that the app menu is not shown in non-gnome environments (as windows
would end up with *two*
  menubars), and hide items already in the app menu from regular menus
when running in gnome

 b) port *all* menus to GMenu, and use gtk_application_set_menubar() to set
the in-window menubar;
 in environments that do not support the app menu, GTK+ will display it
as first item in the menubar
 *automagically*

So for a transitional period, option [2]a is OK, but long term application
should really go with [1] or [2]b.


Regards,
Florian
___
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

[Florian Müllner]

On Mon, May 7, 2012 at 1:41 PM, Matteo Settenvini
matteo...@member.fsf.orgwrote:

 By the way, and slightly unrelated: F10 allows me to pop up the first
 menu, and ALT+letter to open a specific one by accelerator. What is
 the corresponding shortcut for the upper menu?


SuperF10 to open, arrow keys to navigate (I'm not saying that ALT+letter
would be a bad idea, but at least for now we don't support that in any
shell menu, so the app menu is consistent here)


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

Re: Gnome 3 issues

[Florian Müllner]

On Fri, Apr 27, 2012 at 8:40 AM, surma su...@hot.ee wrote:

 That messed up my hands and I can't use mouse.
 That is why I liked gnome 2, everything could be done
 without mouse.


And the same is true for Gnome3 - to navigate to an application, you can use
super  ctrlPgDown  tab  (tab | shifttab | arrow keys)
(or super  ctrlalttab, select Applications, (tab | shifttab
| arrow keys))

Though generally superappnameenter is a lot faster.


Maake it so, under gonf-editor you can choose the layout of the menu.


I encourage you to give the normal Gnome3 experience another shot
(personally I actually consider it more keyboard-friendly than Gnome 2),
but if you insist, you can force fallback mode (at least for now):

System Settings - Details - Graphics - Forced Fallback Mode


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

Re: Gnome 3 issues

[Florian Müllner]

On Thu, May 3, 2012 at 5:18 PM, Emmanuel Pacaud emman...@gnome.org wrote:

 Wouldn't it be better to make right arrow replace the ctrlPgDown
 tab sequence.


ctrlPgUp/PgDown are the standard GNOME shortcuts for switching between
tabs, so I don't think removing them is a good idea. Obviously we could add
left/right as additional shortcuts here[0], but note that there is a GSOC
project to change how the application view is triggered[0], which makes
those shortcuts kinda obsolete.


Regards,
Florian

[0] those might conflict with (currently unimplemented) windows keynav
though
[1] http://jimmac.musichall.cz/log/?p=1181
___
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

[Florian Müllner]

As I understand it, typing the password will switch to the password
dialog, which is about as keyboard/non-touch friendly as it gets :-)

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

[Florian Müllner]

On Thu, Apr 26, 2012 at 4:04 PM, Jeremy Bicha jbi...@ubuntu.com wrote:

 I don't know if Unity supports having both regular menus and a Gmenu
 at the same time.


I don't know either, but I don't think it is relevant here - there is GMenu
support for *both* app menu and window menu in
GtkApplication/GtkApplicationWindow, so as long as the entire menubar is
ported, all of Unity, GNOME 3 and fallback should work as expected. It
might be a good idea to clarify the goal with regard to window menubars
though :-)


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

[Florian Müllner]

On Thu, Apr 26, 2012 at 4:35 PM, Allan Day allanp...@gmail.com wrote:

 In some cases there will be a GMenu and a menu bar (with
 File/Edit/View...) for the same app, at least in the short term.


There is some confusion about terminology here, so Ryan asked me to clarify
:-)

GMenu is a newly introduced technology to implement *both* 'app menus'
(the shell's application menu) and 'menubars' (which looks like a
traditional menubar, but is set with gtk_application_set_menubar()). The
goal should be to port existing menubars to GMenu, either only providing an
app menu, or splitting actions between app menu and menubar. The benefit
will be menus that behave as expected by the environment - GNOME 3 will
display the app menu in the top bar and keep the menubar in the windows,
GNOME Fallback (and Windows) will display both in windows and Mac OS X /
Unity will merge them into the global menu.


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

Re: Module Proposal: Zeitgeist

[Florian Müllner]

On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote:

 do you really want to start talking about what the community think about
 this ? Because if you want to start talking i recommend to see how many
 threads we have, specially on gnome-shell ml, about design decisions that
 makes the community powerless against the almighty Design Team.


... and from before the design team even existed, there are even more
threads about design decisions that make the community powerless against
the almighty GNOME Developers - the (rightful) answer to that is usually
don't just complain, get involved. The same still holds true with the
design team - really, those folks would *love* seeing more people getting
involved.


Regards,
Florian
___
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

[Florian Müllner]

On Mar 20, 2012 9:27 PM, Andre Klapper ak...@gmx.net wrote:
 I normally prefer to say the application that displays web pages when
 talking to non-tech people.

The GNOME Web Blue e
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.4 Features, final round

[Florian Müllner]

On dom, 2011-11-06 at 21:52 +0100, Seif Lotfy wrote:
 Lets avoid the fact that this is by MS, it is still useful to look at.
 http://windows.microsoft.com/en-US/windows7/products/features/jump-lists
 They distinguish between recently and frequently used too

I am not able to see the embedded silverlight movie(?), but the quote

What you see in a Jump List depends entirely on the program.

would support Matthias' comment about defining actions in .desktop
files.


Florian


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

Re: 3.4 Features, final round

[Florian Müllner]

On dom, 2011-11-06 at 22:52 +0100, Seif Lotfy wrote:
 What you see for me doesnt necessarily mean that the program
 populates the jumplist alone. It means the items in the jumplist are
 prgram specific.

To me it means that the application is in control of what appears in the
jumplist, not necessarily that it is responsible for specifying the
exact set of items. So I can imagine some gnome-recent-items action
which is translated appropriately by the shell if included in
the .desktop file, but I would not expect anything in the jumplist if
the application does not specify anything.


 Unless we provide the recentlyused and mostused files in the .desktop
 file the only way for the jumplist to populate itself with such items
 is if the app is running and pushed them into the jumplists.

I don't agree with the notion that jumplist == recently/frequently used
files - for instance for Evolution, I would expect actions like New
mail or Open calendar, but not a list of recently read emails
cluttering the list (even when that data is available in
gtkrecent/zeitgeist).


Florian


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

Re: 3.4 Features, final round

[Florian Müllner]

On lun, 2011-11-07 at 00:23 +0100, Seif Lotfy wrote:
 
 On Mon, Nov 7, 2011 at 12:10 AM, Florian Müllner fmuell...@gnome.org
 
 To me it means that the application is in control of what
 appears in the
 jumplist, not necessarily that it is responsible for
 specifying the
 exact set of items. So I can imagine some gnome-recent-items
 action
 which is translated appropriately by the shell if included in
 the .desktop file, but I would not expect anything in the
 jumplist if
 the application does not specify anything.
 
 
 However if the app doesn't specify a list why not have a fallback
 option.
 Mostly you will end up using it in cases like gedit, rhythmbox, totem,
 epiphany and event documents. In that case I suggest the usage of
 zeitgeist and not gtk.recentmanager. Since such lists are dynamic i
 don't find it appropriate to keep updating the .desktop file with
 recently/most used every time the app is used. If apps really would do
 that I would suggest them push directly into zeitgeist. 


I did not suggest updating the .desktop file, I suggested special
actions applications could specify to request certain content, for
instance a list of recent items. (Obviously that would only be step
three, after deciding whether the feature is wanted and implementing the
basic functionality).


Florian

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

Re: Features !

[Florian Müllner]

On sáb, 2011-10-08 at 11:48 -0400, Jeremy Bicha wrote:
 GNOME's implementation is very young; I have a hard time finding apps
 on my computer using this feature even in GNOME 3.2;

There are no jumplists in GNOME 3.2, which explains your troubles
finding apps making use of this feature ;-)


Florian

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

Re: Features !

[Florian Müllner]

On mié, 2011-10-05 at 16:22 -0400, Jasper St. Pierre wrote:
 For the shell: mode-switch kill? Overview window borders?

Yes, Jakub and me are planning on working on mode-switch kill.


Florian


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

Re: GNOME user survey 2011

[Florian Müllner]

2011/8/1 Felipe Contreras felipe.contre...@gmail.com

 Yes, but if a significant percentage of the people answer not at
 all, or somewhat, then the survey would be a bit wasted, since now
 you have to wait another year to ask in more detail.


Of course the same argument applies if a significant percentage of people
feels that GNOME has too few configuration options.


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

Re: GNOME user survey 2011

[Florian Müllner]

2011/8/1 Felipe Contreras felipe.contre...@gmail.com

 Do the majority of GNOME developers agree that there are too few options?


No.


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

Re: New module proposal: LightDM

[Florian Müllner]

On Fri, 2011-05-13 at 14:59 +0200, Robert Ancell wrote:
 Why replace GDM?
 
 - LightDM is a cross-platform solution.

Will KDE replace kdm with LightDM or drop its non-greeter code in favor
of LightDM? Are there any interesting discussions in the other camp
that you can point us to?

Florian

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

Re: Plugins, modules and extensions

[Florian Müllner]

On Mon, 2011-05-09 at 15:52 +0200, Giovanni Campagna wrote:
 A different issue is then UI. Some time ago it was proposed to introduce
 addons.gnome.org, skip the (rpm/deb) packaging completely and just
 instruct users to go, download the plugin and install it.
 This has the problem that the plugin must be in an installable format
 (xpi?), not just a random python/js file to drop in .local/share (or
 even worse, an autotools tarball).

I'm not sure we need to take extensions into account which do stuff that
requires more than the metadata/js/css files - I'd consider extensions
already as warranty-breaking, and even more so if it requires
compilation/installation outside
~/.local/share/gnome-shell/extensions/foo.

So I'd imagine something simple as a gzipped tarball with a custom
extension (gsx == GNOME Shell extension?) which is distributed on
addons.gnome.org - then we can have a dedicated app (Desktop Extension
Manager?) registered as MIME handler to deal with
installation/removal/disabling/... .

Florian

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

Re: Plugins, modules and extensions

[Florian Müllner]

On Mon, 2011-05-09 at 17:50 +0200, Giovanni Campagna wrote:
 So .gsx (application/vnd.gnome.shell-extension) for the Shell, .gdp
 (application/vnd.gnome.gedit-plugin) for Gedit, .epe
 (application/vnd.gnome.epiphany-extension) for Ephiphany, etc.? How
 would it integrate with, for example, libpeas?

No, I was only talking about GNOME Shell. I don't know if there are any
plans for application extensions to go for the web route as well, but if
they do I don't see how they'd need a dedicated UI - all applications
you mention already provide UI for extension management, it'd seem more
natural to extend those as necessary (of course that doesn't mean that
code couldn't be shared between those applications).

GNOME Shell is a bit special in that it should not have a brand of its
own (e.g. users shouldn't need to know that they are running gnome-shell
any more than they needed to know they were running gnome-panel
+metacity). It's basically the desktop chrome of GNOME 3 - which makes
for a horrible brand :-)

For extensions, this also means that there's no good place for an UI yet
- we don't (and shouldn't) have any GNOME Shell Settings. Looking glass
is a developer tool, I don't think it is where we expect users to manage
extensions. Exposing extensions in the overview (as suggested at some
point) is completely out of the question. Hence my suggestion to have a
dedicated application to manage desktop extensions.

Florian

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

Re: Interested in GNOME on touchscreens?

[Florian Müllner]

On Mon, 2011-03-07 at 14:51 -0600, Brian Cameron wrote:
 An on-screen keyboard GUI probably would not need to be coded
 in Clutter to look well integrated with GNOME Shell, unless there is
 some advantage to coding the GUI in JavaScript, I'd think.

The main selling point for an on-screen keyboard implemented in GNOME
Shell itself is not the look, but rather that it would work in the
overview without jumping through hoops.

Florian

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

Re: My thoughts on fallback mode

[Florian Müllner]

On Tue, 2011-01-04 at 21:07 +0100, Christopher Roy Bratusek wrote:
 Compared to how many users stuff like Compiz, AWN  Co got I would say it's 
 somewhere between 5 and 10%.

Please take AWN (CairoDock, Docky, ...) out of your argumentation -
there's exactly nothing stopping you from using those applications with
GNOME Shell.

___
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

[Florian Müllner]

On Wed, 2010-12-01 at 16:29 -0500, Owen Taylor wrote:
  - We could just make it require GTK+ 3.0. This is my suggestion - 
GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME
(fallback) window manager. GTK+ 3.0 will be released as a
stable toolkit before Metacity 3.0 is released. If people need
to Metacity build against older GTK+, the older tarballs aren't
going to be removed from the website.

+1 from me as well.

There's another thing which came up on IRC - the theme format has been
extended in mutter, and it may be nice to port these changes to Metacity
as well. It would allow the fallback environment to use the new GNOME 3
default theme without the art people having to support two versions (the
theme format is ... not very nice).

Porting the changes should be pretty straight-forward, though the change
to version 3.2 raises another question - it adds a new frame type for
attached dialogs, which is a Mutter-only feature. It is optional, so we
could just
  #define meta_prefs_get_attach_modal_dialogs() FALSE
and only port the theme change, rather than porting the feature itself.


Florian

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

Re: GNOME 2.91/3.0 Schedule Draft

[Florian Müllner]

El dom, 10-10-2010 a las 14:37 +0200, daniel g. siegel escribió:
 On Sun, 2010-10-10 at 13:30 +0200, Andre Klapper wrote:
  Currently UI Freeze starts at Feb 21 (together with 2.91.90 release)
  which would mean six weeks until 3.0.0 is released.
  The request is to move it to Feb 09, 2011 (which would be after the
  2.91.6 release) to have eight weeks.
 
 do you mean march 09?

No, this would make a shorter UI Freeze instead of a longer period as
requested.

Florian


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: (L)GPLv3

[Florian Müllner]

El mar, 06-07-2010 a las 12:32 -0500, Ted Gould escribió:
 On Tue, 2010-07-06 at 13:17 -0400, Ryan Lortie wrote:
  It's the GPLv2 in the program code that states you can't link this 
  against anything other than GPLv2 code.
  
  Nothing we could add to the library licence (other than dual-licensing
  under GPLv2) could fix this.
 
 [...] But, it seems like when we're making a choice between dual-licensing
 v2/3 and v3 with an exception for v2 only -- the exception is the better 
 choice.

Not an expert, but if I understood Ryan correctly, it's v2 which would
need the exception (This program is licenced under GPL v2 only, but you
may link this against anything (L)GPL regardless of version)

Florian


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list