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

[Mattias Bengtsson via desktop-devel-list]

On Mon, 2019-03-25 at 12:22 -0400, Will Thompson wrote:
> 
> [...] In particular, several third-party, non-free apps like Dropbox
> which are partially or totally unusable without a status notifier
> already support it. (Not to make this all about Dropbox – it's just
> an app I use that falls into the "totally unusable" category.)

Hm. I'd like to challenge this. I've used Dropbox for 10+ years and I
forgot it even had a notification icon.

From my experience there aren't many (or even any?) apps that fall on
the partially- to totally unusable scale.

Regards, Mattias

___
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

[Mattias Bengtsson via desktop-devel-list]

On Mon, 2019-03-25 at 10:21 -0400, Pat Suwalski wrote:
> 
> [...]
> Is that a joke? On a default gnome install on any modern screen,
> only about 25% of the top bar contains any information at all. It
> can't be "the most important real estate" and be so underutilized. 

It really can. One stated goal for GNOME 3 was to provide a distraction
free environment to work in. If you expose too much information you'll
add distraction while diluting the information actually provided.

> That said, notification icons are literally the most useful
> information points for the many applications I have running in the
> background. So they deserve prominent placement.

This is rather anecdotal and hard (for the GNOME developers) to act on.
It would be more interesting to know what problems you have with the
current notification system.

> You think "application developers simply cannot live without their 
> application icons being visible at all times"? That's why Windows
> lets you hide them. Problem solved. Like, since XP in 2001.

I think what they did to the notification bar in Windows XP is pretty
weak to be honest. Closer to worst-of-both-worlds than to a solution in
my perspective.

Regards,
Mattias

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

Re: Documents and core apps

[Mattias Bengtsson via desktop-devel-list]

On Thu, 2019-01-17 at 18:06 +0100, Bastien Nocera wrote:
> Nobody added the ability for gnome-documents to open files...
> 
> I'll probably split off Books at some point in the future.

That's great to hear. I'm using Books to read comics, flipping my Yoga
360° to tablet mode, and using it in touch mode is much easier than
Evince.

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Mattias Bengtsson]

On Fri, 23 Mar 2018 10:15:57 +0100,
Milan Crha wrote:
> 
> One thing I didn't find in the manual, or I might just overlook it, is
> there an easy way to write the comment text in a preformatted mode? I
> know I can use  in the comment like here (both with and
> without shown there):
> https://gitlab-test.gnome.org/mcrha/test/issues/4

It's markdown formatted like most of GitLab. So just ask your users to wrap
their backtraces in code blocks, like this:

```
Your Backtrace
```

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

Re: Meson feedback as a user

[Mattias Bengtsson]

On Sun, 2017-07-02 at 17:39 +0200, Sébastien Wilmet wrote:
> My main point of my email was that the Meson documentation should be
> split in two or three IMHO:
> - Simple user doc, how to build a project that uses meson;
> - Doc for developers/maintainers that want to use meson as the build
>   system of their project;
> - Doc for contributors to Meson itself or developers who want to 
>   write a macro/function (I don't exactly know how Meson works, but I
>   suppose it can be extended in some way).

This sounds like feedback perfect for their bugtracker[0] rather than
ddl honestly.

1: https://github.com/mesonbuild/meson/issues
___
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

[Mattias Bengtsson]

On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
> Hi,
> […]
> The typical workflow as advised by github (and therefore I believe
> that's similar in gitlab), if not mistaken, is:

Unless you have push privileges, in which case you'd just create a wip-
or feature branch and make a merge request. This is what's recommended
on the GitLabWorkflows[1] page.

> […] So I just clone the upstream, and only if I end up doing a patch,
> I would only then "fork" on github, then update my local repository
> to point to my "fork", so that I can push then click the "pull
> request" button. That's still very cumbersome.

For most of us active in this discussion, this won't be an issue since
we'll have push privileges (see above). 

However. What you describe above is how I make drive-by patches on
GitHub, and I agree it can be a bit cumbersome. Fortunately there are
tools to help you. I use git-spindle[2] which has support for GitHub,
GitLab and Bitbucket. The, above manual steps becomes something like
this with git-spindle (using graphene as an example repo):

$ git hub clone ebassi/graphene && cd graphene
$ git checkout -b wip/my-cool-fix
 [ do some work ]
$ git commit -a -m "My awesome fix"
$ git hub fork
$ git hub pull-request
  [ Write merge message ]

> IMO this is a completely broken and over-complicated workflow. For
> long term contributors, having their own remote can be
> understandable.
> But for one-time contribs?
> 

With proper tooling, the workflow isn't very complicated at all. And
it's definitely not "completely broken" as you suggest.

Regards,
Mattias

1: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabW
orkflows
2: https://github.com/seveas/git-spindle
___
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

[Mattias Bengtsson]

On Wed, 2017-05-17 at 10:06 -0400, Pat Suwalski wrote:
> On 2017-05-16 07:10 PM, Mattias Bengtsson wrote:
> > How did you install GitLab? We use the omnibus RPM package for
> > CentOS
> > and have had no dependency problems while upgrading from some 7.x
> > release all the way to 9.1.x over the last few years. A lot come
> > bundled in the omnibus package and the rest gets installed from the
> > host operating system repositories.
> 
> There's the difference. I don't trust the current omnibus package, so
> I install from source. That decision is old, but at the time we
> installed, there wasn't an omnibus package.

There lies your problem I believe. I'm pretty sure this doesn't apply
to GNOME.

> A proper package would rely on system libraries only.

Shipping software, targeting multiple Linux distributions is hard. 

> Anyway, this is getting off-topic. Using the only appropriate
> install method for this package takes considerable effort.

It is. I don't agree that a manual installation from source is "the
only appropriate install method". That is a rather extreme position to
take and one I'm sure our sysadmins doesn't hold.

In short, I don't consider this an issue.

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

[Mattias Bengtsson]

Hi Pat!

On Tue, 2017-05-16 at 10:41 -0400, Pat Suwalski wrote:
> I only lurk here, so I don't often offer an opinion, but I do
> maintain the GitLab install at my medium-sized company.

I do the same, but our experiences seems to be pretty different.

> My problem with GitLab is how fluid it is. The underlying
> technologies keep changing, and it's a real pain staying up to date.
> If you get behind at all with the updates, it's quite a chore to
> upgrade, and half way through you find out you need a new Ruby, need
> to upgrade through a couple of packaging systems for node, and
> really, you should just upgrade to Debian unstable (that last one is
> a bit of an exaggeration). 
> Expect a new user interface experience every four months.
> That's not to say that it's fragile. It's been rock-solid for us.

How did you install GitLab? We use the omnibus RPM package for CentOS
and have had no dependency problems while upgrading from some 7.x
release all the way to 9.1.x over the last few years. A lot come
bundled in the omnibus package and the rest gets installed from the
host operating system repositories.

Could it be that Debian stable is just very old? 

> It's just hard to recommend something you can't predict, running 
> ever-changing technologies that no sysadmin can comfortably stay on
> top of.

Since everything has been working super smooth for us I can't say that
I agree (not implying that the pain you've experienced isn't real of
course).

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

[Mattias Bengtsson]

Hi all!

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

This is very exciting! I've been following the plans on the wiki and
the discussions in #sysadmin and have been waiting impatiently for you
to reveal the plans to the public.

As part of my responsibilities at my current work I help maintaining
our internal GitLab CE instance and from my limited experience,
updating and maintaining it has been rather easy.

One exciting thing about GitLab is its fast pace of development. New
releases with new features are coming often.

One question though regarding the GitLab CE merge button:

The merge button in GitLab CE produces (non-ff) merge-commits
which might be undesirable (the history gets really hard to read
IMHO). GitLab EE allows you to rebase and/or perform --ff merges
instead.

At my work we keep a semi-linear git history:
 - we only allow merges based on the tip of master
 - we always merge with --no-ff (which is what GitLab's merge
   button does)

This gives us grouping of commits into features, while still
making sure our history is reasonably easy to follow.

To enforce this with GitLab CE we use a pre-merge CI test that
tries to perform a fast forward merge, and fails if it can't. We
then set the merge setting for the repo in question to not allow
merging MR's with failing CI pipelines.

In GNOME, the most common workflow has been to use a straight
history without merge-commits + release-branches. This implies making
a fast-forward merge or a rebase, which means that the above mentioned
trick won't work with our model.

From my understanding (after reading the workflow description),
the plan is to just not use the merge-button if you want to keep
the current merging model.

This is /definitely/ fine by me, the net gain from moving to
GitLab is still *huge*. But I'm wondering, has there been any
further discussion around this? Has anyone reached out to GitLab
asking if this feature could be moved to CE for us?

Regards,
A very excited Mattias
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)

[Mattias Bengtsson]

Yeah this is so awesome!

/Mattias - who just deleted his IRCCloud account

Den 3 mars 2017 1:57 em skrev "Emmanuele Bassi" :

Thanks ever so much for this work, Matthew. It's really a great
addition to the communication channels for GNOME, and hopefully people
will start using Matrix much more. :-)

Ciao,
 Emmanuele.

On 2 March 2017 at 19:32, Matthew Hodgson  wrote:
> On 03/02/2017 15:57, Matthew Hodgson wrote:
>>>
>>> On 3 Feb 2017, at 13:00, Alexandre Franke 
>>> Matthew, anything blocking the bridging on our side?
>>
>>
>> Nothing blocking at all; it's all on our side, which has ended up
>> blocked on FOSDEM - we've had to prioritise a sprint to ship new
>> releases for FOSDEM and are currently all on trains to Brussels. It's
>> top of the IRC bridging backlog and we should get to it early next
>> week. Sorry for the delay...
>
>
> Hi all,
>
> We've finally set up a bridge hosted by matrix.org that links GIMPNet into
> Matrix (as per the earlier bits of this thread).  Sorry that it took so
long
> to happen: FOSDEM ended up being even crazier than we expected, and we've
> spent the last month handling the traffic increases and operational
> excitements that came off the back of it.
>
> The bridge has been set up to provide access to all of GIMPNet through
> matrix room aliases of form:
>
>  #_gimpnet_${channelname}:matrix.org
>
> e.g.
>
>  #_gimpnet_#gtk+:matrix.org
>
> The easiest way to use the new bridge is probably through Riot, the
current
> flagship Matrix client: URLs for direct access to a room via riot-web are
of
> the form:
>
> https://riot.im/app/#/room/#_gimpnet_#gtk+:matrix.org
>
> You can also join using "/join #_gimpnet_#gtk+:matrix.org" style syntax,
or
> using the graphical room directory (button linked from the bottom left).
>
> We haven't turned on guest access on the bridge, so users are forced to
> register an account (and go through a captcha) before joining channels.
>
> You can spot folks connecting via Matrix as by default they have a [m]
> suffix on their nickname.
>
> Feedback very welcome!  We are still in beta, and very interested in
making
> sure it fits the bill for communities like GNOME :)
>
> Matthew
>
> --
> Matthew Hodgson
> Matrix.org
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



--
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Multi DPI user interface

[Mattias Bengtsson]

On tis, 2016-07-19 at 23:03 +0800, Jonas Ådahl wrote:
> [...]
> Any opinions on in what way we should deal with this? What user
> interface do we want?
> 

I always found it weird that taking a screenshot or making a screencast
took the data from both screens and put them together.

I'd suggest that the simple PrtSc button just takes a screenshot of the
screen where your mouse cursor is (and for extra visibility just shows
the flash animation on that particular screen).

For Ctrl+Shift+Alt+p-screencasts I'd do the same but make up some way
to show which of the screens are being casted.

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

Re: [Builder] Developer experience (DX) hackfest 2016

[Mattias Bengtsson]

Den 30 dec. 2015 8:36 fm skrev "Christian Hergert" :
>
> I did contact her yesterday and the answer was jitsi. It seems
> reasonable, but I haven't had a chance to test it out yet.
>
> https://jitsi.org/

I've used it once or twice and it worked fine then FWIW.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: HighDPI instructions for developpers

[Mattias Bengtsson]

sön 2014-10-05 klockan 15:34 +0200 skrev Pierre-Yves Luyten:
 Hi,
 
 is there some wiki page to help devs with HighDPI support?
 It is not that easy to follow-up current state in different libraries,
 plus settings-daemon settings, and probably many other factors I do not
 know yet.
 
 I guess some avoid these bad practices / recommandations might be
 useful too.

Good suggestion!

 Moreover, many devs cannot test this themselves.

Doing 

$ GDK_SCALE=2 nautilus

or for a clutter using application

$ CLUTTER_SCALE=2 GDK_SCALE=2 gnome-maps

...works pretty fine for me.

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

Re: Geoclue needs your help!

[Mattias Bengtsson]

On fre, 2014-01-24 at 20:06 +, Zeeshan Ali (Khattak) wrote:
 So what I would really appreciate is for you nice folks to consider
 installing Mozstumblr on your android phones (if you have one, that
 is) and make our geolocation framework work as well as we all want it
 to.

Installing it now. Consider Gothenburg, Sweden covered! ;)

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

Re: Just change release date (Was Re: State of gvfs in Gnome 2.21)

[Mattias Bengtsson]

On Wed, 2008-02-13 at 01:26 +0100, Matteo Settenvini wrote:
 Moreover, a regression is a regression, and should be prioritized. Btw,
 how much useful is having WebDAV and ObexFTP in before normal FTP
 support?

No idea what is used the most or anything. But i use ObexFTP daily at
work transfering applications to my cellphone.


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: State of gvfs in Gnome 2.21

[Mattias Bengtsson]

On Wed, 2008-01-23 at 18:41 -0500, Pat Suwalski wrote:
 It might not be the right location for this button, but it's more useful 
 there than nowhere.

I would say that it probably isn't. I've been using GNOME for about 3
years now and never knew that that button (or fonts:/// for that matter)
ever existed. Good to know, but some UI love would probably be in
order. :)

/Mattias - just a user

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

Re: Pulseaudio

[Mattias Bengtsson]

On Fri, 2007-10-12 at 18:21 -0400, Ronald S. Bultje wrote:
 It's simply too long. I'm not going to pick out what's important or 
 relevant in the discussion.
 
 Let me re-phrase it: if you can't make it clear in ~10 lines why PA is
 a must-have, it probably isn't. How you phrase it is a matter of
 philosophy. 

I'm really just a lurker of this list but i got too frustrated by your
writing to not end my silence.

Your two last posts have been highly arrogant and trollish. Lennart was,
as he said himself, away during most of the conversation in this thread.
Considering all the questions asked and general concerns brought up in
this thread and how technical in nature they have been the reply was
bound to be long. You are, of  course, free to not read it. 

I bet Lennart could write less then 10 lines to describe why PulseAudio
is a must-have, that was however not at all the meaning of that post.
He was mearly answering questions and concerns brought up in this
thread.

Mattias



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