Re: Chrome Remote Desktop Support for GNOME/Wayland

[Nicolas Dufresne]

Le mardi 25 janvier 2022 à 16:30 +, S . via desktop-devel-list a écrit :
> Hi All,
> 
> (Please feel free to advise of appropriate mailing list if you think this
> doesn't fit here)
> 
> I am looking into supporting CRD for GNOME/wayland. CRD would be leveraging
> remote desktop APIs (along with screencast) as exposed by xdg-desktop-
> portal{,-gnome}. While experimenting with remote desktop APIs, I see that for
> enhanced security, an interactive dialog (relevant code:
> https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/screencast.c#L345-349
> ) is always presented to the user to select sources/devices they want to allow
> to be remote controlled. Though this workflow would make perfect sense when a
> user is directly connected to the machine and is allowing someone remote to
> take control (e.g. to get help from IT) but it is less than ideal for a user
> who is trying to access their own machine remotely (e.g. accessing their work
> computer from home).

If you visite the screenshare configuration panel, you have two choices,
interactive or password driven. The second is non-interactive. The visual
addition telling the user that the display/screen/window is share does not seems
like a problem to me, but indeed possibly make a bit less sense outside of
remote support kind of use case.

> 
> I would like to hear ideas from the GNOME community about how to best support
> the latter use case for remote desktop. Is there a secure way to bypass the
> dialog/prompt selectively for apps? There seems to be recent support for

Note that VNC/password in that context is not very secure, should likely be used
in local and controlled network. But this is specific to VNC and might not be
relevant what you suggest.

> restoring the capture streams (if persistence was demanded previously by the
> user) using flatpak permission
> store:https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests
> /14 but remembering streams for remote desktop session is explicitly
> disallowed in the portal frontend
> (https://github.com/flatpak/xdg-desktop-portal/blob/master/src/screen-cast.c#L
> 589-L594 -- though this doesn't seem to be GNOME specific). Is it reasonable
> to extend the stream restoration support to work for remote desktop sessions
> as well as pre-populating the permission store to allow remote desktop session
> (so that user intervention can be avoided)? Also, would pre-populating the
> permission store work for system installation of CRD or would only work for
> flatpak/sandboxed version of the app?
> 
> Looking at how other software/systems are supporting screen capture/remote
> desktop, we see wlroots/sway allows for configuring the output screen to
> capture in a config file
> (https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/xdg-desktop-po
> rtal-wlr.5.scd#description). I believe Windows.Graphics.Capture APIs can also
> allow Win32 apps to capture a window/screen without user interaction.
> 
> Would love to hear thoughts from the community about the best way forward.
> 
> Thanks,
> Salman
> 
> 
> ___
> 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: sorry if this is the wrong place

[Nicolas Dufresne]

Le lundi 14 septembre 2020 à 15:35 +0200, Daniel Mustieles García via
desktop-devel-list a écrit :
> This feature is called "Fractional Scaling". There are several
> articles related to his explaining how to set different scaling for
> two displays in the same system.
> 
> Don't want to give you concrete example webpages because I've not
> tested them and I don't want to confuse you, but a quick search in
> Google might help.

Fractional scaling is about being able to scale by a non multiple, like
125%, 150%, etc. It's quite nice if you need something rendered bigger
(overall, not just the fonts) but don't want to turn your 4K monitor
into a 1080p high resolution surface. Note that this is enabled by
default on latest Ubuntu I believe, it has some issue with legacy X11
application (you might see some blur). To enable, and then restart you
session.

gsettings set org.gnome.mutter experimental-features 
"['scale-monitor-framebuffer']"
https://www.omgubuntu.co.uk/2017/09/enable-fractional-scaling-gnome-linux

This feature request is different though, it's about allowing to change
the font size in the theme per monitor. Note that changing font size
often affect layout and may break the theme. It remains that if there
is enough traction, such feature could possibly be nice, could even
become a per monitor theme and apply to other use cases, like using
high-contrast on LED secondary screens (like some phone overlays, or
action camera secondary screens).

Nicolas

> 
> Regards
> 
> El lun., 14 sept. 2020 a las 14:52, Francis Grizzly Smit (<
> griz...@smit.id.au>) escribió:
> > I wish to make a feature request for the gnome desktop, and I
> > cannot find anyway on the gnome.org sites to do this 
> > 
> > basically I have a problem with desktop font scaling I have a new
> > 27" hi resolution (3840 x 2160 (16:9)) monitor and a older 27" with
> > lesser resolution (1920 x 1200 (16:10)), now the fonts on the hi-
> > res monitor were too small for my eyes, the lower res one was fine,
> > now the  display options would let me scale the monitor, but I only
> > need the fonts to be bigger not anything else (so this is a total
> > waste), so I scale the fonts in gnome-tweak, this works fine on on
> > the hi res monitor at 1.40 but it also scales the lower res
> > monitor, which is a total waste, but is better than the other.
> > 
> > 
> > 
> > so my feature request is that the font scaling be  split per
> > monitor so I can have font scaling on the hi-res monitor to 1.40
> > and leave the other one at 1.00 
> > 
> > 
> > 
> > Hope this is not too hard to do, yours sincerely Francis Grizzly
> > Smit.
> > 
> > -- 
> >.~. In my life God comes first
> >/V\ but Linux is pretty high after that :-D
> >   /( )\Francis (Grizzly) Smit
> >   ^^-^^http://www.smit.id.au/
> > ___
> > 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

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

Re: [GitLab] What 11.6 brings to us

[Nicolas Dufresne]

Le dim. 23 déc. 2018 07 h 36, Carlos Soriano  a écrit :

> 11.6 is here, there are a few nice things for us.
>
> *Run CI/CD for merge requests
> *
> CI are not only for branches, but also for MR. Variables, etc. can be put
> to adjust the CI to do X or Y things on MR or regular branches. This will
> be very handy if we need to go back to only do fast CI for the GNOME group.
>
> *Suggested Changes in MRs
> *
> Provide suggested changes in MRs and apply them at merge. This was raised
> in the postmortem email by a few people, so try it out and let me know how
> it works for you. AFAIK the implementation is similar to the one in GitHub.
>
> *Similar issues suggestions when filing a new issue
> *
> Duplicate issues handling was one of the top priorities for us, so GitLab
> has requested our feedback for this new feature. So please try it out and
> let me/them know how does it work for you.
>
> Cheers!
>

Let's hope we can change their mind on keeping code review comment batching
a paid feature. It makes gitlab looks bad by spamming patch submitters on
long reviews.


___
> 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: GitLab postmortem

[Nicolas Dufresne]

Le mardi 11 décembre 2018 à 14:22 +0100, Carlos Soriano a écrit :
> Hey,
> It has been a few months since we moved to GitLab. Apart of spurious issues, 
> specific annoyances and frustrations, seems it has been generally good. I 
> would like to gather some general feeling about it. Things that really made a 
> constant impact to you and your work, both bad or good. Feel free to provide 
> feedback about the transition or the administration of GitLab instance too. 
> Free form.
> 
> Please keep the mail chain one way from you towards the world, so we don't 
> get trapped on specifics, we can address stuff raised here individually out 
> of list. Personally, I'll ping you on IRC or so if I can do something to help.
> 
> Of course, feel free to msg me directly on IRC/email too.

1. No Cross-Project CI supportIt's a bit off topic, as GStreamer is on FDO now. 
But the one thing that had hit was how complex the CI deployment across 
multiple projects (repository is). We really miss the pipeline aggregation on 
trigger that exist in the EE version. The side effect, builds are scattered 
across all repo, instead of being centrealized on the specific build system 
repo (in our case cerbero and gst-build). So looking over all builds is near 
impossible. The caches are always cold, because the build is too scattered. 
So all in all, what I really miss is that ability to trigger another project 
(repository) pipeline and gain an aggregated pipeline. With Jenkins, it fully 
centralized, hence much simplier, but still, now we can per commit CI, which is 
great.
2. No multi-commit codec review workflow
Unlike github, there is no fluid way to navigate through each commits one by 
one during the review. The stack of commit is also upside down for a review. I 
generally endup opening commit in browser tabs, but that's not idea. Note that 
this is probably not a regression from bugzilla, but I was surprise to find out 
how inferior this is in gitlab in contrast to gihub.
> Thanks all!
> 
> ___desktop-devel-list mailing 
> listdesktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list


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

Re: Question on Librsvg

[Nicolas Dufresne]

Le ven. 5 oct. 2018 16 h 30, Ray Wu via desktop-devel-list <
desktop-devel-list@gnome.org> a écrit :

> Dear Sir,
>
> I am a developer looking for an SVG parser and renderer that can work with
> Windows.  I am developing my application using MFC and C++. I searched
> online and found Librsvg is a very popular and very good SVG library.
> However, I notice that your project is mainly for linux system. I wonder if
> Librsvg could work with Windows 7 (64bit) and can it work with MS visual
> studio?
>

In GStreamer project, we have successfully build and use the pre-Rust
version on win64 using Mingw toolchain. I have no idea about the Rust
version. The generated libs work fine in MSVC projects, but they don't come
with compatible debug symbols though.




> Your answer is very much appreciated.
>
> Thanks,
> Ray
> ___
> 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: [GitLab] Gravatar vs libravatar

[Nicolas Dufresne]

Le lundi 03 septembre 2018 à 21:16 +0200, Alexandre Franke a écrit :
> On Mon, Sep 3, 2018 at 8:13 PM Carlos Soriano 
> wrote:
> > Hello all,
> > 
> 
> Hi,
>  
> > If you have any other comment, feel free to provide it here or in
> > the issue.
> > 
> 
> For those who may not know it yet, libravatar is decentralized and
> federated alternative to gravatar. It has a few free software
> implementations (including the one used on the main public instance)
> and one can host their own instance or use a public one. We should
> encourage the use of such services rather than centralized ones based
> on non free software.
> 
> It’s worth noting that Damned lies already supports libravatar.

So it's a gain in privacy if you want to host your own. I'm surely not
the only one that isn't going that extreme in keeping control over
couple of my pictures flying around and won't go that far.

That being said, for people my me, where to I upload yet another
picture ? Any free hosted services ?

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


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

Re: Python 2 support in GNOME build tools

[Nicolas Dufresne]

Le dimanche 15 juillet 2018 à 12:54 +0200, Christoph Reiter via 
desktop-devel-list a écrit :
> > My understanding is that the main blocker for using Python 3 is
> > that RHEL/CentOS 7 doesn't have it built-in, only as part of a secondary
> > "software collection"?
> 
> Yeah, that's also what I heard when the topic came up on IRC, but similarly
> vague re RHEL.. :)

Stable distribution shouldn't block software from going forward with
Python 3. Simply because stable OS won't update to whatever we release
next, unless it's bug/security fixes.

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

Re: GitLab CI runners for non-Linux systems

[Nicolas Dufresne]

Le vendredi 18 mai 2018 à 19:16 +0530, Arun Raghavan a écrit :
> On 18 May 2018 at 18:51,   wrote:
> > On Fri, May 18, 2018 at 5:52 AM Philip Withnall 
> > wrote:
> > > 
> > > Can anybody else provide and maintain CI runners for other platforms?
> > > I’d particularly like to see:
> > >  • *BSD (probably OpenBSD and NetBSD)
> > >  • macOS (ideally several versions, since we support from OS X 10.7
> > > upwards[2])
> > >  • Android (probably a cross-build)
> > >  • More Windows configurations (currently we have MSYS2 on Windows
> > > Server 2012; ideally we’d have a MinGW-w64 runner too)
> > 
> > 
> > I can help write the CI job configurations for macOS, but I don't know how
> > to host or set up a runner.
> > 
> > (For a shortcut solution, we could consider farming out the macOS builds to
> > Travis CI, which has macOS runners already available)
> 
> If anyone can point me to how to set up an Android runner I could try
> to pitch in there.

We had a vague idea that we would hook the Android device to a Lava
lab, and use LQA utility to trigger the run from the cross-build docker
instance. We (Collabora) are not yet ready, but we'll be able to share
some Lava lab time for this if it works / needed.

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

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

Re: Making a phone call with GNOME

[Nicolas Dufresne]

Le jeudi 15 mars 2018 à 15:41 +, Bob Ham a écrit :
> On 15/03/18 14:48, Nicolas Dufresne wrote:
> > Le jeudi 15 mars 2018 à 10:39 +, Bob Ham a écrit :
> 
> >> There's no existing dialer in GNOME
> 
> > Note that this is not entirely true, there is a dialer in Empathy
> > already. It's most likely a miss-fit for a Phone UI (just like most
> > Gnome application if left unmodified).
> 
> To be clear here, when I say "dialer", I mean something with a typical
> phone interface; a 3x4 grid of buttons with numbers, '*' and '#'.  I
> know Empathy can request channels from telepathy-ring⁰, I've got it to
> do that with an SMS channel but couldn't seem to poke it into requesting
> a call though I expect it's possible.  Is that what you mean when you
> say there's a dialer in Empathy or is there a 3x4 button grid somewhere
> that I missed?

To be clear, I mean that Empathy Call UI have a dial pad with all this
with the DTMF implemented. So the code is there. Mostly all what we did
on the Nokia phone was also implemented in Empathy for SIP. What's
likely missing, is to enable that UI to initiate a call. What I don't
mean to, is that this is not ready for a Phone UI, it needs a design
and a better workflow.

Also, from random Google Image search:
http://fortintam.com/blog/wp-content/uploads/empathy-3.6-and-pulseaudio-2.0.jpg

Nicolas

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

Re: Making a phone call with GNOME

[Nicolas Dufresne]

Le jeudi 15 mars 2018 à 10:39 +, Bob Ham a écrit :
> Hi all,
> 
> I'm working on the ability to make a phone call with the Librem 5 phone.
>  I've started working on a Telepathy-based dialer and call handler.  The
> goal at Purism is to work upstream and we use GNOME as the desktop
> environment in our distribution, PureOS, which will be what the Librem 5
> runs.  There's no existing dialer in GNOME so the assumption underlying
> this work is that it will end up as "GNOME Dialer".  I'm sending this
> email now to check in and get feedback on my approach.

Note that this is not entirely true, there is a dialer in Empathy
already. It's most likely a miss-fit for a Phone UI (just like most
Gnome application if left unmodified).

> 
> There was a long discussion⁰ last year on this mailing list regarding
> replacing Telepathy with Matrix and the thread also included a lot of
> general discussion of Telepathy and communication.  In that discussion
> there were plenty of calls for Telepathy to die so I feel I should
> justify my approach.
> 
> Firstly, there are only two existing free GSM middleware frameworks:
> freesmartphone.org¹ (FSO) and oFono².  FSO is actually a whole
> smartphone middleware, including not just telephony but contacts,
> alarms, audio, battery and so on.  We are explicitly targetting the
> GNOME platform which already provides a lot of (all of?) what FSO does.
> We cannot use FSO or else we would conflict with our goal of building on
> the GNOME platform.  Hence, we must use oFono.

oFono is also the best choice for telephony. It has been extensively
tested and used in read-world use cases. It also handles well the
Bluetooth Handset and implement all the features you car integration
needs. Though, it might not have a great upstream at the moment (non
have)

> 
> Both Telepathy and oFono expose APIs over D-Bus so regardless of whether
> we use oFono natively or through telepathy-ring, we'll be writing a
> GNOME D-Bus application.  By building a dialer based on Telepathy we get
> the tantalising possibility of supporting SIP cheaply as there are SIP
> connection managers for Telepathy.

Telepathy Ring was justified by the "single UI" requirement to
aggregate GSM / SIP / XMPP (which included Google and Facebook back
then) / IRC but also proprietary stuff like Skype. As of today's
reality, Matrix native API is missing, and only GSM/SIP/IRC remains
(well haze, for libpurple, but a bit limited), from which only GSM and
SIP have strong common needs. That's why Telepathy is being criticized,
as it's very complex for what it brings.  A simpler abstractions would
make everyone's life easier.

> 
> By using telepathy-ring we also open the possibility of having deep
> integration of SMS and IM systems.  That's not the immediate focus but
> it's something to bear in mind.
> 
> When I read through the Telepathy Developer's Manual, I thought "this is
> awesome!"  However, having got to grips with a lot of the complexity, I
> can see why there has been so little traction and why a lot of people in
> the aforementioned mailing list thread wanted it to die.  That said, I
> still think Telepathy is awesome and it still seems like the most
> sensible choice for our immediate need of building telephony programs
> for the Librem 5.

It was designed for a phone, and made useful to the desktop.

> 
> My colleague François Téchené recently wrote a blog post³ proposing a
> unified UX using a "feature"-based approach rather than an
> application-based approach.  This proposal comes from the ideas of
> Ethical Design⁴.  The technological underpinnings of this UX are already
> largely extant in Telepathy.
> 
> The future that I'm looking towards is one where the Librem 5 is a
> shining beacon of harmonious Telepathy-based telecommunication magic,
> providing unified interfaces to various different messaging and
> audio/video telephony systems including Matrix, GSM, SIP and XMPP,
> complete with encryption.

Maybe you want to finish the Telepathy 1.0 spec then ? It's a major
cleanup that go abandoned when Nokia Open Source went down. All the
code is still available. It removes the legacy/backward compatibility,
removes the duplicated interface (specially for Telephony, as there was
couple of rewrites of this interface, and we ended up supported
multiple versions in Empathy).

> 
> I understand that this is no small undertaking, to say the least.  We
> will not achieve this state when the Librem 5 first ships.  However,
> over time I would like us to work towards that harmonious magic.
> 
> Thoughts are most welcome.
> 
> Thanks,
> 
> Bob
> 
> 
> ⁰
> https://mail.gnome.org/archives/desktop-devel-list/2017-August/thread.html#00112
> https://mail.gnome.org/archives/desktop-devel-list/2017-September/thread.html#00047
> ¹ http://www.freesmartphone.org/
> ² https://01.org/ofono
> ³ https://puri.sm/posts/librem5-progress-report-8/
> ⁴ https://2017.ind.ie/ethical-design/
> 
> ___

Re: Bugzilla migration tool user accounts

[Nicolas Dufresne]

Le jeudi 30 novembre 2017 à 12:54 +0100, Alexandre Franke a écrit :
> On Thu, Nov 30, 2017 at 6:43 AM,   wrote:
> > Bastien, do you also mean to imply that the wish to be subscribed
> > to >2000
> > issues means that receiving >2000 mails won't be a problem?
> 
> It will be a problem, but not as bad as losing subscription on those
> issues. It would still be very much worth looking for a way to
> temporarily disable notifications to avoid that flood. I can also
> imagine that sending that many email out at once can raise some flags
> and make GNOME look bad in the eye of some email providers.

This was an issue when some project tried to migrate to Phabricator.
The server end up stalled for days, spamming everyone. We need to be
careful.

Nicolas

signature.asc
Description: This is a digitally signed message part
___
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

[Nicolas Dufresne]

Le mardi 28 novembre 2017 à 14:56 +0100, Bastien Nocera a écrit :
> Hey,
> 
> On Tue, 2017-11-28 at 04:21 +, philip.chime...@gmail.com wrote:
> > Hi list,
> > 
> > This is about the migration tool for Bugzilla bug reports to GitLab
> > issues. See, for background, issues [1] and [2]. Currently, the
> > migration tool posts all the migrated issues and their associated
> > comments as one single user; either the maintainer who runs the
> > script, or a special 'bugzilla-migration' user.
> 
> At the very least, I'd expect people who were on CC: for the Bugzilla
> bugs to also be CC:ed on the GitLab issues.
> 
> I'm currently on the CC: list for more than 2000 bugs in Bugzilla. That
> doesn't cover modules for which I'm a co-maintainer and would have
> received automated -ma...@gnome.bugs emails. I would hate to have to
> resubscribe to every one of those by hand.
> 
> I already found the 20-odd bugs I was CC:ed on in gnome-calendar a pain
> to resubscribe to, so you can imagine with 2k bugs.
> 
> Also, my GNOME.org gitlab registered e-mail address isn't the same as
> my bugzilla mail address. It's another problem you might run into with
> the migration script.

To be checked in the script, but you have to make sure your bugzilla
email is listed in gitlab (it supports multiple email). After migration
there will be no issue removing old emails. You can also change your
email in bugzilla too if you want, that works these days.

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

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

Re: Relicensing Nautilus to GPLv3+

[Nicolas Dufresne]

Le mercredi 17 mai 2017 à 14:55 +, Frederic Crozat a écrit :
> Le mer. 17 mai 2017 à 16:02, Ernestas Kulik  a
> écrit :
> > (Attempt no. 2, since Geary hates me)
> > 
> > Hi,
> > 
> > As the current licensing situation in Nautilus is quite
> > complicated, I
> > and Carlos are planning a move to relicense the entire codebase to
> > GPLv3+.
> > 
> > The codebase has files under several licenses: LGPLv2+, GPLv2+ and
> > GPLv3+, the latter implicitly making the project be licensed under
> > its
> > terms, so our options are quite limited here.
> > 
> > The situation wrt extensions is also not entirely clear, as the
> > extension library is LGPLv2+ with Nautilus being GPLv2+, which in
> > turn
> > disallows loading non-free extensions. Given the fact that it is
> > not
> > meant to be a generic mechanism for loading extensions, I feel like
> > relicensing it without much consideration is reasonable.
> 
> I know at least one proprietary extension  for Nautilus (integration
> with Synology NAS product) and I'm not sure we should prevent
> proprietary extensions to be used for Nautilus.

You can just mimic Totem exception clause. This is used to allow
proprietary GStreamer plugins.

https://git.gnome.org/browse/totem/tree/COPYING#n345

regards,
Nicolas

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

Re: GitHub Development Platform for GNOME

[Nicolas Dufresne]

Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit :
> On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  m> wrote:
> > I want to share my humble opinion and thoughts about GitHub/GitLab:
> > 
> 
> From what I've been hearing, people within GNOME have been evaluating
> the possibility of running our own GitLab instance, so I would wait
> and see what the results of their testing is.

And we need not to forget that a lot of the freedesktop community [0]
projects are moving to Phabricator (even though it does not come with
an easy patch submission mechanism).

regards,
Nicolas

[0] https://phabricator.freedesktop.org

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

Re: Do not use -Werror by default in your modules without joining #testable

[Nicolas Dufresne]

Le dimanche 02 avril 2017 à 14:59 +0100, Emmanuele Bassi a écrit :
> Yes, I know: this would be slightly more easier if Continuous warned
> about build breakages via email (though I'm pretty sure email would
> still be a high latency medium that tends to be ignored);
> nevertheless, joining the #testable IRC channel *today* to get a
> notification of build failure is *not* a heavy burden — especially
> now
> that we have the Matrix bridge and you don't even need an IRC client
> running at all times.

Is this important for projects that already have their own CI system ?
(notably GStreamer). It does seems like an overhead to track two CI, I
do believe that build breakage due to warning should be quite rare in
GStreamer case. Please let us know.

Nicolas 


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

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

[Nicolas Dufresne]

Le lundi 10 octobre 2016 à 22:51 +0900, Tristan Van Berkom a écrit :
> 
> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch,
> and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Glib meson branch can be found here:

https://github.com/centricular/glib

best regards,
Nicolas
___
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

[Nicolas Dufresne]

Le mardi 29 décembre 2015 à 12:56 +, Jasper St. Pierre a écrit :
> If there is no free solution that has a similar easy setup
> experience, perhaps the GNU project should invest in building such a
> service.

If you can afford to focus on WebRTC based solution, implementing an
Open Source service shall keep the complexity to it's lowest. Though,
the stability will depend on the quality of the browser WebRTC support,
that's where the complex code is. You could also achieve better privacy
then most proprietary services, though this is at the cost of bigger
bandwidth and possibly bigger processor power on client side.

cheers,
Nicolas

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

Re: GNOME Shell browser plugin

[Nicolas Dufresne]

Le vendredi 06 novembre 2015 à 16:05 +0100, Carlos Garcia Campos a
écrit :
> Of course it would be better to switch to any other thing that works
> on
> all browsers, but what?

We could create a websocket service on localhost, and create a simple
Web page that speak with that service. Websocket is not supported by
libsoup, so writing GLib code is really simple.

cheers,
Nicolas

signature.asc
Description: This is a digitally signed message part
___
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

[Nicolas Dufresne]

Le 2014-12-05 04:33, Tristan Brindle a écrit :

On 5 Dec 2014, at 1:42 pm, Tristan Brindle t.c.brin...@gmail.com wrote:

It looks like the Windows equivalent is the PlaySound() function[0].

So I guess there are a couple of possible approaches if we don’t want GSound to 
stay as a separate library:

Having given it a bit more thought, there is a potential (possibly crazy) third 
option:


3) Add the GSound API to GIO as an extension point, but implement it directly 
using GStreamer, and don’t use libcanberra at
Setting up GST each time will be too slow. Having GST linked around will 
also have the side effect that one 1 of 0.10 or 1.0 will be usable with 
GLib app. 0.10 is nearly dead, but it's still a little bit soon for 
that. Doing it with pulse will be better, as you can upload your sound, 
and get it to play when needed. Some Alsa code, as a fallback to not 
having pulse would work relyably to. Obviously you'll need OSS for BSD 
and friends.


Nicolas

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

Re: Visual effects

[Nicolas Dufresne]

Le mardi 05 août 2014 à 14:30 +0200, Sébastien Wilmet a écrit :
 I've tried recently KDE, and by default it has too much visual effects,
 IMHO. With time, it seems that GNOME follows the same path, there are
 more and more visual effects.

Fortunately, there is an extension to let you use snappy (or only
faster) animations.

https://extensions.gnome.org/extension/277/impatience/

cheers,
Nicolas



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

Re: Going to Montreal again

[Nicolas Dufresne]

Le vendredi 13 septembre 2013 à 10:16 +0200, Hubert Figuière a écrit :

 I haven't found the venue (IRC, mailing list) to volunteer to help. I
 happen to now live in Montréal and I am willing to offer help


You can join #montreal on Gimpnet.

regards,
Nicolas

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

Re: Background Opacity in gnome-terminal 3.8.1

[Nicolas Dufresne]

Le dimanche 26 mai 2013 à 12:52 +0200, Stefan Sauer a écrit :

 I just upgraded and I miss it too :/


I'll miss it too. I currently use that on daily basis so I can test
video playback behind my gdb terminal. This is very handy when I have
only 1 screen, which is the case when travelling.

Nicolas

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

Re: GObject error handling questions

[Nicolas Dufresne]

Le mardi 21 mai 2013 à 13:34 +0400, Nikita Churaev a écrit :

 Is it an OK way to report error locations?


Looks fine to me.

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

Re: GObject error handling questions

[Nicolas Dufresne]

Le mardi 21 mai 2013 à 05:11 +0400, Nikita Churaev a écrit :

 1. Is there a way for a GObject constructor to fail and report an error?

Yes, you should implement GInitiable 

 
 2. Is it possible to attach additional information to GError (file where
 the error came from, line and column)? If not, what is the standard way
 to report these?

No, GError::message is designed to be displayed on screen, error
targeted to developers shall be displayed in the terminal (probably
using g_error, or assertions). The domain and code shall be used
whenever run-time handling of the error shall be made. 

 
 3. How to localize errors?

Like any other string in your applications _(text).

I hope that helps,
Nicolas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Question About File Roller

[Nicolas Dufresne]

Le mardi 16 octobre 2012 à 12:31 -0500, Ma Xiaojun a écrit : 
 Well, I don't think file archiver is an unimportant component of desktop.

Small project does not mean unimportant. Small simply means that a
limited effort is needed to keep it up to date, and working with latest
libraries. This so far, has worked great in this project, just like any
other Gnome project of this size.

 It may have relatively small codebase currently, tough.
 What if you find yourself have trouble opening an archive from your
 professor or boss?
 File a bug on Bugzilla? Contact the author by E-mail directly? Ask in
 desktop-devel-list?

If you find a bug, you open a bug ticket in Bugzilla. This is the same
rule for all the projects regardless of their size. Sending private
e-mail to author and developers shall be restricted to security issues.
Finally, mailing list are mostly for user support, design discussion,
etc. Those subject are usually split between mailing list to reduce
traffic.

 I don't think a mailing list is an overkill.
 Some mailing lists on other application are not that high volume too.

Again, all Gnome project have a mailing list, but smaller projects
shares this mailing list as need. Again, we don't often have file-roller
being a top topic, this project seems to just work at the moment.

 
 I would also run 7-zip with wine to workaround some problems.
 But this should be a solution you would like, right?

Using Wine in general does not seems right to me. If you are having
issues with 7-zip support, then file a bug, and properly describe the
problems and step to reproduce.

 
  As per the other things, this is open source, it sure would be great if each
  app and library had up to date information and dedicated resources but our
  resources are limited to the people stepping up to do the job.
 I know this for sure.
 
  If you think the file roller wiki page needs updating, this could be a great
  opportunity for you to cotribute to GNOME. Just figure out what's missing
  and what needs updating and add it yourself, that's what wikis are for. Any
  help is welcome Ma, thanks a lot for your feedback and I look forward to
  your contributions!
 There isn't a portal-like wiki page yet.

Well, if you thinks it's useful, create one,
https://live.gnome.org/FileRoller . Clearly the sourceforge page is an
ancestor, all the source code has been moved to gnome.org now.

regards,
Nicolas

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

Re: Question About File Roller

[Nicolas Dufresne]

Le mardi 16 octobre 2012 à 14:04 -0500, Ma Xiaojun a écrit : 
 On Tue, Oct 16, 2012 at 2:00 PM, Debarshi Ray rishi...@lostca.se wrote:
  #gnome-hackers on GIMPNet
 
 Do you accept questions like I cannot open RAR on Fedora.
 I do know the answer.
 But that's the kind of user support question I mean.

This is distro specific, but it's any easy one.
1. Enable RPM fusion on your system http://rpmfusion.org/Configuration
2. Install rar and unrar (sudo yum install rar unrar)

regards,
Nicolas

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

Re: Question About File Roller

[Nicolas Dufresne]

Le mardi 16 octobre 2012 à 14:26 -0500, Ma Xiaojun a écrit : 
 I said I know the answer.
 
 What about this kind of question?
 https://mail.gnome.org/archives/evince-list/2012-October/msg8.html

This is a larger project, for this reason it seems that the maintainer
have their own mailing list. If I had notice this thread, I would most
likely have suggested use mailing list mentioned on there freedesktop
page[1]. Asking on this mailing list seems fine, since one need to learn
that Poppler is the backend library that does all the job.

Bascially, there is no magical answer. It's case by case.

[1] http://poppler.freedesktop.org/

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

Re: make --silent

[Nicolas Dufresne]

Le vendredi 14 septembre 2012 à 20:48 -0700, Maciej Piechotka a écrit :

 In any case - people who care the most would be the one who have the
 most knowledge to just change it locally (say use -s flag). 


What about alias make=make -s V=0 ?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: avoid to select between different proxies

[Nicolas Dufresne]

Le vendredi 10 août 2012 à 19:46 +0200, Blackhold a écrit : 
 Hi,
 I'm using gnome2 and tested gnome3, but I miss a very important thing.
 
 in gnome 2 you could have a list of proxies, but in gnome 3 you can

That is unclear to me how you could have that in gnome2. Gnome 3 should
behave the same as Gnome 2 in term of proxy logic. There might be a bug
in the new proxy code now in glib-networking library. Would be nice to
provide with full scenario.

 only select 1. This is useful if you are working between different
 proxies, in the new way I have to have a text document saved anywhere
 with the common proxies I use.

For more complex proxy settings, I usually recommend using an JavaScript
PAC file**. In your gnome setting, choose automatic, set an URI like
file:///home/me/my.pac . With a PAC file you can do a lot more, like
choosing proxies base on domain, or current subnet, etc.

** See http://en.wikipedia.org/wiki/Proxy_auto-config.

cheers,
Nicolas

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

Re: 3.2 features: login screen

[Nicolas Dufresne]

Did anybody consider including language selection in the initial setup
screen. It a little hard to do that at the moment. Being able to change
the system language seems to be missing too, Gnome has to provide
something as distro are not support to extend the control panel so much.

Nicolas


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: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

[Nicolas Dufresne]

Le mercredi 11 mai 2011 à 08:44 -0400, Matthias Clasen a écrit :
 On Wed, May 11, 2011 at 7:05 AM, Guillaume Desmottes gdesm...@gnome.org 
 wrote:
  Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit :
 
 
  That will hopefully be superseded by the Web Accounts panel David is
  working on.
 
  But shouldn't we wait that the Web accounts panel is actually a full
  super-set of Empathy's panel (and not just some mockups) before removing
  the lib?
 
 No. We don't want the crazy (sorry...) list of chat protocols in
 there, I think. The way I envision this to work for both empathy and
 for evolution is that the apps will pick up configuration for the
 major web accounts (google, facebook,...) from the web accounts panel,
 but still offer their own configuration for things like bare imap (in
 evo) or irc (in empathy).

And what happen if Empathy fades away, if Gnome Shell becomes the
Telepathy Handler ? Does it mean Gnome will no longer support less known
protocols ?

Nicolas


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: GNOME Feature Proposal: Backup

[Nicolas Dufresne]

Le mercredi 11 mai 2011 à 12:16 +0100, Bastien Nocera a écrit :
  FWIW, this is exactly the use-case I'm missing. I would like to copy
 my
  personal data to an external hard drive, remote server or cloud
 storage
  service, so that if my hard drive goes boom, I can get my settings,
  documents, photos, etc back after installing a new distribution on a
 new
  system. I'm not that bothered about a full system recovery for a
 GNOME
  back-up tool.
  
  So I applaud your focus :)
 
 That's because you're lead to believe that it's enough :) 

From desktop point of view, we usually do no modification of any kind
except for /home. It takes 20-30 minutes to install a distro these days,
and same to install a system backup. Base on that, doing a full system
backup seems a waste to me. As long as I can recover my home into some
newly created user account, I think it's enough. Also, when a hard disk
breaks, I tend to buy a bigger one. Using distribution installer let me
reconfigure the partitioning (or let the distro do it) from an user
interface I already learned before.

For sure, if your looking for server backup it's a different story. But
in reality, servers these days are not backup using integrated UI. Most
of the time, server are virtual, which makes backups something really
different.

Also, my previous experience trying to help someone using Time Machine
and Time Capsule on OS X was not so great. It ended up using the capsule
as a hard-drive and simply copying manually stuff over, as it was much
simpler to get stuff back.

The tech support argument is interesting, but my corporate experience
tells me that we never endup having full system backup for user
Desktop). The reason is that it's time and disk consuming. What I've
seen the most, is user profile being store on central server, and tools
to track software and licenses on each desktop. I'm guessing on this
one, but also tools to reinstall from the ground those machine with the
same softwares and licenses.

At last, I don't think the futuristic system wide backup should delay
having per-user backup. When this advance system wide backup support
exist, we could simply improve the UI and give more options to
administrators, and if an admin has setup system wide backup, cleanly
inform the non-privileged user that backup is already configured by the
system administrator. I would be really surprised such a complex system
wide tool gets written and reach a solid state soon, and even there, I
would be really surprise if sys-admin would start using such a young
implementation right away. Also, restoring user home from a user setting
is quite simple, but restoring a full system requires alternative OS,
which is usually distro expertise, not a UX expertise (I don't agree
Gnome 3 is an OS, but its clearly a UX).

cheers,
Nicolas


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: SoC idea: desktop file cache

[Nicolas Dufresne]

Le mercredi 30 mars 2011 à 22:01 +0300, Adrien Bustany a écrit :

 Note that for big data transfers, using FD passing and a socket is
 quite faster, but probably overkill here. 

This is what we use for file transfer in Telepathy.

regards,
Nicolas


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

Bump libproxy requirement

[Nicolas Dufresne]

Hi all,

as many may have noticed, GLib 2.26 gains proxy support with
configuration being provided by libproxy (through plugin in
glib-networking ). The problem is that current recommended version of
libproxy (0.4.0 on the wiki and 0.4.3 in jhbuild) does not work when
used through a plugin, see libproxy issue 133.  This issue has been
fixed in version 0.4.5, which is the version I would like to bump to.

Best regards,
Nicolas


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: Bump libproxy requirement

[Nicolas Dufresne]

Le mardi 31 août 2010 à 11:48 -0400, Nathaniel McCallum a écrit :

 One further point of clarification is that 0.4.5 is a bug fix release
 and does not change API or ABI. 

There is no API/ABI changes in this release. For your information, all
0.4.X are aimed at incremental bug fixing.

Best regards,
Nicolas


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