Re: GNOME Music needs you!
On Sat, 2015-12-26 at 10:14 -0500, Vadim Rutkovsky wrote: > Music should include files from ~/Music and ~/Downloads only. > If some other files are played - please file a new bug (please > attach the output of 'gnome-music -d' to help debugging it). Ah, I see. I've set my Downloads folder to be ~/Desktop, and I use this to dump stuff temporarily, so there's some unrelated junk there. Is there a way to exclude the Downloads folder? 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 Music needs you!
On Saturday, 26 December 2015 14:43:22 GMT, Vadim Rutkovsky wrote: * There's no way to shuffle through my w library. This is almost always how I use Rhythmbox, so I won't switch to GNOME Music until that's possible. I wrote a quick patch to add an All Music playlist, but I can't test it because of https://bugzilla.gnome.org/show_bug.cgi?id=759751 IIRC the intended way is to switch to Songs view, start playing any song and change play mode to Shuffle. This is how I've been using Music the whole time (no need for any patches), seems to work fine for me. The only thing that drives me crazy, is that this is supposed to be a music player, yet rather than indexing my music collection in ~/Music, it has chosen to index every single audio file it can find anywhere in my home directory. Which means when I shuffle all songs, it keeps playing random audio files that are not part of my collection, and are not songs at all. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A bitcoin wallet for gnome
On Thu, 2015-11-12 at 22:39 -0300, Hugo Alejandro wrote: > https://mail.gnome.org/archives/foundation-list/2013-July/msg00016.html > > As proposed, it would be good to consider as having a virtual wallet > app for gnome-core, with support for bitcoin. > > It has been several years and now feels safer in the future be used in > a common way, virtual coins so a virtual wallet would be part of any > desktop environment. I have been thinking about this recently too. I don't think I have the time to work on this myself. But, I have been working on an Ubuntu phone app in Python. So, if anyone decides to start this project, and wants to do this in Python, I'm happy to work on the backend, as this work will likely be the same across both programs. But, I don't have the time at the moment to work on the frontend. 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
401 error
I've failed to get any response at all from the GNOME shell list, so I'm
posting this to a couple of other related lists, to see if I can get any
support. My extension has stopped working in GNOME 3.14+ due to a 401
error. Can anybody help with this? Details below.
On Sat, 2015-06-20 at 00:45 +0100, Sam Bull wrote:
> On Sat, 2015-06-13 at 10:54 +0100, Sam Bull wrote:
> > On Mon, 2015-06-01 at 09:53 +0100, Sam Bull wrote:
> > > In GNOME Shell 3.14, on Ubuntu 15.04, my extension is no longer able to
> > > sync to Owncloud due to a 401 error. Is there a change to
> > > Soup.message.new() that causes it to use cookies or something? I am
> > > trying to authenticate by passing the username/password in the URL. I'm
> > > not sure if there is an option to disable cookies or something else I
> > > need to do to get the authentication working.
> > >
> > > Details: https://github.com/owncloud/notes/issues/109
> > >
> >
> > Does anybody have any idea? I still haven't got this working.
> > Soup.Message.new("GET",
> > "http://user:p...@owncloud.url/index.php/apps/notes/api/v0.2/";)
> > just keeps giving a 401. I can test this in curl and it works fine. This
> > used to work before I upgraded to Ubuntu 15.04/GNOME 3.14. This is also
> > broken on my Gentoo box with GNOME 3.14, where it was working fine on
> > 3.12.
>
> So, further research has led me to try connecting to the 'authenticate'
> signal of the session, but this never gets triggered. So, I figured that
> maybe I need to explicitly enable authentication, but the functions to
> do this don't work. The error I get is:
>
> (gnome-shell:1470): libsoup-WARNING **: soup-session.c:887:
> invalid property id 18 for "add-feature-by-type" of type
> 'GParamGType' in 'SoupSession'
> (gnome-shell:1470): Gjs-WARNING **: JS ERROR: TypeError:
> httpSession.add_feature_by_type is not a function
>
> With the code:
>
> const httpSession = new Soup.Session();
> httpSession.add_feature_by_type(Soup.TYPE_AUTH_BASIC);
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: GTK+3/Win32 : looking for help
On ven, 2014-06-06 at 22:24 +, C. Thomas Stover wrote: > No, that's why I asked. GIMP and Inkscape are great. I use them both. > Though do many people use them on windows? This is a serious question. I've seen several people use GIMP on Windows, and I've spoken to many less technical people who are aware of GIMP, but have never heard of Linux. So, I would suggest that, yes, many people use GIMP (and maybe Inkscape) on Windows. I would imagine there are download statistics somewhere which can help confirm that. 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: App menu Help/About consistency
On Tue, 2013-12-10 at 10:32 -0600, Michael Catanzaro wrote: > Say you have Epiphany open on workspace 1, and another one open on > workspace 4. If you use Quit from the app menu, then both windows are > going to be closed, but you probably only intended to close one of them. > > Terminal and Evince purposefully do not have Quit in the app menu for > this reason. I expect to be able to quit a web browser like Firefox, having all the windows close (and possibly re-open when launched again). But, with evince I just expected that each window was a separate program instance. So, in that case, quit would terminate the focused program instance. I had no idea that when opening unrelated documents in evince that all the windows were being managed by one central program. There is no indication that the windows are all connected under the same program. Though now thinking about it, I'm struggling to pin down exactly what suggests to my mind that Firefox or Libreoffice windows belong to a single instance. 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 keyring unlocking
On Thu, 2013-10-10 at 20:12 +0300, p10 wrote: > The problem > is that if someone manages to hack his way into my account/computer (say > there's some SSH/VNC/Bittorrent sync/whatever else vulnerability) I > don't want my passwords in plain text. > > if you unlock the > keyring every user-space app can access the stored passwords . (?) > Ideally certain apps would get access to certain keys . Right, that is what I was getting at. If the keyring is unlocked, they are going to have full access to it, regardless of how they get in. Stef has been talking about storing the keys with each individual application, which will improve the situation, as apps won't be able to get other apps passwords. But, I don't believe root is involved. So, if they are actually logged into your account, via SSH or something, then I presume they would still have full access to that information. (Otherwise, how would the user be able to manage their own keyring?) 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 keyring unlocking
On Thu, 2013-10-10 at 10:28 -0500, Michael Catanzaro wrote: > I missed the distinction between login tasks (wireless networks, > Telepathy accounts) and non-login tasks (web/email passwords) that Sam > Bull has pointed out. So maybe non-login-related passwords could still > be protected by default. Something I've been thinking about, is if we used 2 keyrings by default, one unprotected and one protected. Then in the password dialog, we could have a radio button like: x Don't store this password Store this password for later: x Unprotected (or 'Unlocked at login') x Using my master password Or some wording along those lines. The unprotected one is the login keyring, which is technically still protected if you login, but has no protection if you autologin. Then the master password one is a second keyring with a separate password. This can then still be used by regular login users as a way of adding an extra layer of security. I'd be interested in working on this, but I don't have the time to spare at the moment. 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 keyring unlocking
On Thu, 2013-10-10 at 13:13 +0300, p10 wrote: > if you're going to enter your password after 5 seconds anyway, which > makes this feature incompatible with "Online accounts" . My solution is to use two keyrings. I have a passwordless keyring for IM and other stuff that is accessed immediately on auto-login. Then I have a protected keyring that stores the passwords for Evolution, encrypted folders and other things I want to keep secure. This means I only need to enter the password when I open Evolution or something protected, and not immediately everytime I turn the machine on. Which also means I can give it to a friend and let them browse the internet or whatever without worrying about them accessing private data. You seem to be under the impression that auto-login should in some way be just as secure, without any form of authentication. If you don't need to enter a password, then it doesn't matter what technical wizardry you use to unlock the keyring, all someone needs to do is turn your computer on, and they have full access to your stuff. You must either choose to have your data protected or unprotected. Using the two keyring mechanism, like me, you can choose that on a more fine-grained level, rather than having to make everything unprotected though. 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: Application menus
On Fri, 2013-07-05 at 11:01 +0200, Bastien Nocera wrote: > Which is exactly one of the reasons why focus-follows-mouse isn't an > option we offer/isn't supported. Umm, it is offered, and appears to be supported. It can be enabled in Tweak tool. I say it appears to be supported, because a delay was added a version or two ago, which solves the issue with the global menu. It means you can flick the cursor to the top of the screen without changing focus, and thus access the menu. Not sure why this person is not able to reach the top of the screen with one quick flick, but it works for me. 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
