Re: Proposal: Replace all references to master/slave in GNOME modules
On Wed, 2019-05-01 at 23:31 +1000, Michael Gratton wrote: > It is telling that no one is complaining about replacing uses of > "slave" by itself alone. What a completely bizarre thing to say. The word "slave" doesn't have a whole slew of homonyms with different meanings. Only one verb. So where "slave" has been used, it often does have the connotation that you want to Bowdlerise. While the various other words spelled "master" don't have that connotation at all. If you don't understand the distinction, you really don't seem to have been listening at all. smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2019-04-25 at 13:04 +0200, Bastien Nocera wrote: > > Besides, we can't use "mainline" anyway, as that is a reference to > > intravenous drug taking and since we can't be expected tell homonyms > > apart or pass basic primary school comprehension exercises by > > applying our knowledge of context to the words we see, we'll *obviously* > > interpret all instances of the word "mainline" as references to > > drugs... right? > > This is a "slippery slope" logical fallacy. Are you going to argue that > we can't use "trunk" either because of its link to deforestation? ;) Why not? It makes just as much sense as eschewing "master" and "mainline". I see it more as "proof by contradiction". The logic in this request appears to be of the form: • Word X has bad connotations • Word X' is a homonym of word X • Therefore we must avoid all uses of word X and its homonyms like X' with related etymology. The logic is just fundamentally flawed, which is quite clear to see as soon as you try to apply it to the general case. And if you want to claim that I'm making the logic excessively broad, and that the case of master¹ vs. master⁶ is somehow different to the case of mainline¹ vs. mainline², or trunk¹ vs. trunk², then I would happily listen to your explanation of what makes them different. As a software engineer, I much prefer to fix bugs rather than paper over them with workarounds. And if the bug here is that some people wouldn't pass a high school comprehension test because they can't tell the difference between different words that happen to be spelled the same, then changing a small handful of examples doesn't really address the real problem. It's a workaround, not a fix. smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2019-04-25 at 12:12 +0200, Bastien Nocera wrote: > It's easier to completely remove "master" to remove mentions of > "master/slave" and to remove the non-gender neutral "master" than it > would be to do half of that. Two birds, one stone. Haha. I see what you did there. But no, we're not talking about removing the "non-gender neutral master" either. Yes, there is a gender-specific word "master" which is also a homonym of the one in "master/slave". No, that isn't the one which is used when we say "the master copy" or "the master branch". Besides, we can't use "mainline" anyway, as that is a reference to intravenous drug taking and since we can't be expected tell homonyms apart or pass basic primary school comprehension exercises by applying our knowledge of context to the words we see, we'll *obviously* interpret all instances of the word "mainline" as references to drugs... right? smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2019-04-25 at 12:43 +0200, Bastien Nocera wrote: > On Thu, 2019-04-25 at 11:33 +0100, Richard Hughes via desktop-devel- > list wrote: > > On Thu, 25 Apr 2019 at 06:21, wrote: > > > This should go without saying, but master branches are not a > > > reference > > > to slavery, rather to canonicity. The master branch is the > > > canonical > > > branch, the primary copy. > > > > This is very much my thinking too. I'd agree with this proposal if > > every branch forked from master was called slave/hughsie/whatever but > > in this case the master is clearly referring to the canonical version > > that the others are derived from. The word "master" isn't a bad word, > > and doesn't always mean the opposite of slave. > > It's non-gender neutral, which was mentioned earlier in the thread. It's not, which was mentioned earlier in the thread. At https://www.google.com/search?q=master+definition there is a definition of various noun, adjective and verb forms of the word "master". The master/slave definition is #1 in the list of nouns. #2 is also gender-specific, as is #5. But #3, #4 and #6 are not gender-specific, and #6 is the word that's used in the context of "master branch". Claiming that "master branch" is gender-specific is just plain wrong. smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2019-04-25 at 11:45 +0200, Bastien Nocera wrote: > You also don't get to call reasoning you don't agree with "bizarre and > illogical" without justifying it. The reason behind this possible > change was already mentioned in the original mail. The mail's hard to > read, but fairly short, and clearly shows that this isn't about > twisting words. I read the email. It said it was about removing references to the terms "master" and "slave". But then went on to advocate removing a different word which just happens to be a homonym for one of the above. Which is why I called it bizarre and illogical. Even if we accept the initial premise that history can be fixed by whitewashing it and never speaking of it again and never even using terms that can accidentally *remind* people of it... extending it to homonyms makes no sense at all. smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2019-04-25 at 18:13 +1000, Michael Gratton wrote: > On Thu, Apr 25, 2019 at 00:20, mcatanz...@gnome.org wrote: > > We should go to reasonable lengths to avoid offending reasonable > > people, but if someone is offended by innocuous phrases like Master's > > degree, master plumber, Masterpiece Theater, or the word "masterful," > > then I'd suggest rethink why and consider that it's probably not > > reasonable. > > This is objection 1) from the original proposal. Sadly, neither you, > nor I, nor dictionaries get to choose what terms carry current or > historical significance, positive or negative. But we do. When faced with the deterioration of language, with people bizarrely choosing to interpret a given word using one meaning of it, when that is clearly not the meaning that was actually intended... we have a choice. We can capitulate, and say "oh, well if you're *offended* then you must be right, however bizarre and illogical your assumptions are". Or we can stand up and say "no, stop being silly." People in this case seem to be doing the latter. I can't say that I disagree with them. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 13:27 +0100, Simon McVittie wrote: > > (This also prevents use of generated bindings; any method which a > client wants to gracefully fall back from should be called using > a generic D-Bus method invocation rather than a specific generated > binding.) > > and I'm not sure why. I've opened > https://bugs.freedesktop.org/show_bug.cgi?id=106862 to try to clarify this. If the generated bindings are in a library that properly uses symbol versioning (which much of GNOME unfortunately seems to eschew), and if the client library is shipped along with the service, it should all work out fine. Just adding the new API to the client library and not having any proper symbol management, of course, is just the same problem we have elsewhere and not at all DBus-specific. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 09:03 +0200, Milan Crha wrote: > > If you think the D-Bus service version bump was unnecessary, then I > will revert it. I only thought that it was cleaner, because the C API > function will not fail due to missing D-Bus interface method (to be > honest, I do not know what the GDBusProxy will do when the running > interface doesn't contain all the methods it expects to have). Hm, isn't this what we have introspection for? I don't *assert* that it was unnecessary... but I kind of *hope* it was unnecessary, and if it really was necessary then I'd hope someone is fixing things so that in future it *wouldn't* be necessary. :) smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wayland screen capture
On Thu, 2018-05-03 at 23:16 +0200, Antonio Ospite wrote: > On Thu, 03 May 2018 22:00:06 +0100 > David Woodhouse <dw...@infradead.org> wrote: > > [...] > > > > It would be really useful if there was a library somewhere, with > > a simple function to call for "prompt the user and then give me > > a GStreamer src element", which worked on all platforms. > > > > That's essentially what I've provided in the Pidgin code. Except > > someone more competent would ideally have written it. > > > > Is there somewhere that functionality should live? > > Maybe an autoscreencapsrc GStreamer element which can select the > screen capture element/mechanism automatically (ximagesrc, > gdiscreencapsrc, a possible portalsrc), along the lines of autovideosrc. It needs a UI element to interact with the user (especially in the X11/GDI/OSX cases). I don't know if that really lives in the element itself. The Pidgin model is to interact with the user and *choose* the source element (and its parameters), then go off and establish the connection in the protocol code and instantiate the src element once the pipeline is ready to receive it. Which means that if you say "share screen..." and then hit cancel when choosing what to share, nothing happens on the wire. That two-stage setup seems to make sense... which is another reason I'm a little dubious about doing it all automatically in the src element. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wayland screen capture
On Mon, 2018-04-30 at 17:18 +0200, Jonas Ådahl wrote: > On Mon, Apr 30, 2018 at 01:36:48PM +0100, David Woodhouse wrote: > > > > I've just added screen sharing support to Pidgin, based on ximagesrc: > > > > https://bitbucket.org/pidgin/main/pull-requests/330#Lpidgin/gtkrequest.cT1783 > > > > It's not wonderfully pretty, but it basically works, under X. I don't > > like the fact that I ended up using XQueryPointer(), but I don't think > > gdk_device_get_window_at_position() works for *foreign* windows, does > > it? > > > > More importantly, it's completely hosed for sharing either the full > > desktop or individual windows which are Wayland clients. And I have no > > real clue how to fix it. Suggestions please... :) > > > > > On Wayland, you should use the API provided by xdg-desktop-portal: > org.freedesktop.portal.ScreenCast. It is not directly related to X11 > though, and should work the same no matter what windowing system you > use. Read more about it here: > > https://wiki.gnome.org/Projects/Mutter/RemoteDesktop Thanks for this and further help on IRC. I now have Pidgin screen sharing (to Amazon Chime¹) working from raw X11, portal and maybe also via gdiscreencapsrc on Windows. That full patch is at http://david.woodhou.se/pidgin-screenshare.patch Or just the latest PipeWire bits, at http://david.woodhou.se/pidgin-share-pipewire.patch I need to tidy up some of the error handling and failure cases. It would be really useful if there was a library somewhere, with a simple function to call for "prompt the user and then give me a GStreamer src element", which worked on all platforms. That's essentially what I've provided in the Pidgin code. Except someone more competent would ideally have written it. Is there somewhere that functionality should live? -- dwmw2 ¹ https://github.com/awslabs/pidgin-chime smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wayland screen capture
On Mon, 2018-04-30 at 20:43 +0100, David Woodhouse wrote: > On Mon, 2018-04-30 at 17:29 +0200, Jonas Ådahl wrote: > > On Mon, Apr 30, 2018 at 04:23:51PM +0100, David Woodhouse wrote: > > > On Mon, 2018-04-30 at 17:18 +0200, Jonas Ådahl wrote: > > > > > > > > On Wayland, you should use the API provided by xdg-desktop-portal: > > > > org.freedesktop.portal.ScreenCast. It is not directly related to X11 > > > > though, and should work the same no matter what windowing system you > > > > use. Read more about it here: > > > > > > > > https://wiki.gnome.org/Projects/Mutter/RemoteDesktop > > > > > > Thanks. That looks reasonable to implement, at least for full-screen > > > sharing. I'll come back to individual windows later. If I update to > > > Fedora 28 do all those instructions about having to rebuild stuff for > > > myself and enable the features go away? > > > > Right, no need to rebuild anything. > > > $ gsettings get org.gnome.mutter experimental-features > ['screen-cast', 'remote-desktop'] > $ python3 gnome-screen-cast.py > Traceback (most recent call last): > File "gnome-screen-cast.py", line 51, in > session.Start(dbus_interface=screen_cast_session_iface) > File "/usr/lib64/python3.6/site-packages/dbus/proxies.py", line 145, in > __call__ > **keywords) > File "/usr/lib64/python3.6/site-packages/dbus/connection.py", line 651, in > call_blocking > message, timeout) > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Failed to > start screen cast: Couldn't connect pipewire remote Ah, it works if I manually start /usr/bin/pipewire. Is that supposed to get started automatically? Is my client (Pidgin) expected to start it if needed? Or should I check if it's running, and just not offer screen sharing functionality if it isn't? smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wayland screen capture
On Mon, 2018-04-30 at 17:29 +0200, Jonas Ådahl wrote: > On Mon, Apr 30, 2018 at 04:23:51PM +0100, David Woodhouse wrote: > > On Mon, 2018-04-30 at 17:18 +0200, Jonas Ådahl wrote: > > > > > > On Wayland, you should use the API provided by xdg-desktop-portal: > > > org.freedesktop.portal.ScreenCast. It is not directly related to X11 > > > though, and should work the same no matter what windowing system you > > > use. Read more about it here: > > > > > > https://wiki.gnome.org/Projects/Mutter/RemoteDesktop > > > > Thanks. That looks reasonable to implement, at least for full-screen > > sharing. I'll come back to individual windows later. If I update to > > Fedora 28 do all those instructions about having to rebuild stuff for > > myself and enable the features go away? > > Right, no need to rebuild anything. > $ gsettings get org.gnome.mutter experimental-features ['screen-cast', 'remote-desktop'] $ python3 gnome-screen-cast.py Traceback (most recent call last): File "gnome-screen-cast.py", line 51, in session.Start(dbus_interface=screen_cast_session_iface) File "/usr/lib64/python3.6/site-packages/dbus/proxies.py", line 145, in __call__ **keywords) File "/usr/lib64/python3.6/site-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Failed to start screen cast: Couldn't connect pipewire remote -- dwmw2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wayland screen capture
On Mon, 2018-04-30 at 17:18 +0200, Jonas Ådahl wrote: > > On Wayland, you should use the API provided by xdg-desktop-portal: > org.freedesktop.portal.ScreenCast. It is not directly related to X11 > though, and should work the same no matter what windowing system you > use. Read more about it here: > > https://wiki.gnome.org/Projects/Mutter/RemoteDesktop Thanks. That looks reasonable to implement, at least for full-screen sharing. I'll come back to individual windows later. If I update to Fedora 28 do all those instructions about having to rebuild stuff for myself and enable the features go away? smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Wayland screen capture
I've just added screen sharing support to Pidgin, based on ximagesrc: https://bitbucket.org/pidgin/main/pull-requests/330#Lpidgin/gtkrequest.cT1783 It's not wonderfully pretty, but it basically works, under X. I don't like the fact that I ended up using XQueryPointer(), but I don't think gdk_device_get_window_at_position() works for *foreign* windows, does it? More importantly, it's completely hosed for sharing either the full desktop or individual windows which are Wayland clients. And I have no real clue how to fix it. Suggestions please... :) smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome evolution and RFC 6186
On Tue, 2018-04-03 at 07:30 +0100, André Rodier via desktop-devel-list wrote: > Hello all, > > I hope I am posting on the right mailing list. I am working on a project > that installs an email server from scratch. > > I am setting up DNS records for email services automatic discovery (RFC > 6186) but it seems that evolution is ignoring them. You might do better on the evolution mailing list (now in Cc), or just bugzilla. > However, something is definitely working, as my domain is hosted on > Gandi, and the automatic settings come back with Gandi IMAP/SMTP > records, even if I don't use Gandi to host emails. > > What is the logic used by evolution to automatically discover email > parameters? I don't think Evolution ever got RFC6186 support. See discussion at https://git.gnome.org/browse/evolution/tree/src/mail/e-mail-autoconfig.c#n18 It might make a decent GSoC project. It would also be useful to delegate the various protocols' autodiscover mechanisms to the back ends, instead of having protocol-specific knowledge for EWS, ActiveSync, IMAP and other stuff hard-coded into Evolution itself. smime.p7s Description: S/MIME cryptographic signature ___ 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
On Thu, 2018-03-15 at 19:13 +, Simon McVittie wrote: > On Thu, 15 Mar 2018 at 10:39:39 +, Bob Ham wrote: > > 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. > > Unfortunately, the technological underpinnings of that UX are also a > large part of why Telepathy is no longer actively developed. Designing > an abstraction across protocols that are not "the same shape" is really > hard. Maintaining that abstraction in Telepathy soaked up a lot of > developer time, and the need to keep that abstraction API-stable made it > disproportionately hard to add new features (which is why, as previously > noted, Telepathy had trouble keeping up with "modern XMPP": adding a > new feature required touching at least three projects, and making it > API-stable often required investigating multiple protocols to make sure > the API would fit them all). Going back to the discussion last year, again this is one of the aspects that Pidgin/libpurple handles fairly decently. It supports multiple protocols through its messaging and media APIs, with various underlying feature sets. Now that I spend *most* of my work conference call time in Pidgin, I'm thinking of adding voice call support to its SIP protocol plugin. My USB wireless headset is nicer than my DECT one :) smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Google Hangouts support
On Wed, 2017-10-18 at 11:42 +0300, pec...@gmail.com wrote: > > Is there any interest/desire to see Google Hangouts support in > Empathy and Telepathy? Or as Telepathy is on it's way out it is no > interest? > > Or we are looking forward to use more open source friendly chat > platforms? There was talk recently of moving to libpurple as the core infrastructure for such things in GNOME, which made a lot of sense to me. There is a purple-hangouts back end which looks like it's actively maintained, although I've no personal experience of it. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote: > Correct, it's nothing like running a Bitlbee. The typical starting > point is to use an existing hosted bridge to the protocol of your > choice that someone is running (e.g. matrix.org or disroot.org). > Obviously this means trusting that server with your account on that > network, but one can always go and run one's own (which means running > your own server & bridge somewhere - similar complexity to running an > ircd + ircservices). Well, my primary use cases are Lync, which authenticates with my local Kerberos TGT and thus I'd need to be running the server & bridge on my own laptop, and internal IRC where I suppose I could live with running a server *somewhere* in the corporate network. But for the naïve user case, that doesn't really seem like a step forward. Matrix as just one protocol that's supported, sure. But it doesn't seem to fill the gap that Telepathy or libpurple do. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 17:43 +0100, Matthew Hodgson wrote: > > Just to be clear, Matrix is *not* trying to be a > one-protocol-to-rule-them-all, any more than libpurple is trying to be > one-API-to-rule-them-all. Matrix is just doing the same thing: > abstracting multiple networks behind a single API. The difference to > libpurple is that the abstraction happens serverside by default rather > than clientside. > > (Although we do have matrix-appservice-purple, which uses libpurple > serverside as a way to bridge to other networks, a bit like bitlbee but > talking Matrix on the frontend rather than IRC). What is the user experience here? Not like users being expected to do something "a bit like" setting up bitlbee, one hopes? :) If I've got this shiny new Matrix-replaces-Telepathy GNOME system, and I want to add a new account with a new protocol... what do I need to do? Let's assume I've just installed the appropriate distro package, and want to take it from there. (Although do feel free to talk about how it auto-installs the correct protocol package on demand, if you prefer). smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 10:21 -0500, Gary Kramlich wrote: > > It's also a little hard to add the new features that we need, as things > > stand. I actually ended up backporting a bunch of stuff from 3.x to the > > 2.x branch a while back, to support everything that Lync needed. I'm > > kind of resigned to the fact that I might need to do the same, for the > > protocol I'm working on now. > > Dang, well let me know where I can help. Thanks. I think you've actually already done the most useful thing, which is to give me commit access and tell me to go ahead and backport the missing features to 2.x that I needed. That meant that the lack of a 3.0 release didn't actually prevent me from being able to ship those features at all. Obviously where I'd want to *change* an API rather than adding one, that approach is more complicated, but we've been able to cope so far. At some point I need to reinstate my access now that the repo has moved to bitbucket, and then I can start submitting patches for review again. On the whole, I quite like the idea of switching from Telepathy to libpurple. Much more than assuming a one-protocol-to-rule-them-all approach. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 09:51 -0500, Gary Kramlich wrote: > > > > On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse wrote: > > > > > > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: > > > > > > > > If someone cares enough to implement support for a protocol in > > > > Telepathy, they could probably implement support for the protocol > > > > elsewhere too. > > > But where is "elsewhere"? If not libpurple, where *should* I be adding > > > support for my new toy protocol for example? If you've just taken your > > > ball and gone home... > > > > Well why not libpurple? > > As the current lead developer of Pidgin, and thus libpurple, I would > love to see more people using it. if there's something we can do to > make Pidgin/libpurple a stronger contender in this race, please let me > know. Release 3.0? :) Seriously, all that nice GObjectification cleanup does make it a nicer proposal as a GNOME framework. It's also a little hard to add the new features that we need, as things stand. I actually ended up backporting a bunch of stuff from 3.x to the 2.x branch a while back, to support everything that Lync needed. I'm kind of resigned to the fact that I might need to do the same, for the protocol I'm working on now. But overall, I think libpurple does a fairly good job, even if it needs a little updating to handle the needs of some new protocols. > Your critiques about needing updates for newer protocols are certainly > valid, and we're slowly marching towards them as we're trying to > modernize our codebase. That said if anyone would like to discuss > them in more detail, I'd love to hear it (off list naturally). For my part I haven't quite got there yet. I'm filling in the parts of the protocol support that libpurple *can* represent, before I turn to the bits I actually want to extend libpurple for. Top of my list will be persistent messages, read receipts and multi-way V/V calls though. And I've already been asking on the devel list about why Pidgin has no way to display presence status or full names for an "unknown" person who sends me an IM, even though my prpl has it and could tell you. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: > On Fri, Aug 25, 2017 at 2:05 PM, David Woodhouse <dw...@infradead.org> wrote: > > But isn't that the *point*? We have a framework with plugins for all > > manner of different protocols, instead of a mess of separate protocol- > > specific clients each of which can handle only *one*. > > When the choice is given to me between sticking to an abstraction that > tries but doesn’t manage to grasp the quirks of several protocols, or > switching to a protocol specific API and embrace it to make sure it is > correctly and fully supported, I pick the latter. Even if I have to do > it twice or more. I don’t think the *point* should be to support > several protocols badly. That's very true, and I don't think you're wrong to want a Matrix- specific UI which doesn't attempt to use Telepathy at all. I'm just nitpicking that this isn't a "replacement for Telepathy"; it's rightly ditching Telepathy and just doing your own protocol-specific thing. It's slightly suboptimal for *me* because I'm working on protocol support for Yet Another IM Protocol, as well as occasionally still prodding at the siplcs Lync support, and really don't want to live in a world where each protocol needs to put together its *own* GUI to support it specifically. Right now I'm building my toy as a Pidgin/libpurple plugin but not because I particularly like Pidgin; I think it's fairer to say that I just hate libpurple less than I hate everything *else*. It also has the impedance mismatches and doesn't support some of the things I need like persistent editable messages, read receipts, multi-way V/V calls with indication of who's speaking at any given moment, etc... but it *could* be added... > I also don’t think we should aim at supporting all the protocols that > exist. I don’t think a single client can map to the features of all of > them. Just because it's been done badly/incompletely that doesn't mean it's impossible. > If someone cares enough to implement support for a protocol in > Telepathy, they could probably implement support for the protocol > elsewhere too. But where is "elsewhere"? If not libpurple, where *should* I be adding support for my new toy protocol for example? If you've just taken your ball and gone home... smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 13:56 +0200, Alexandre Franke wrote: > On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges wrote: > > > > All in all, if desirable, Matrix and GNU Ring could be connection > > managers in Telepathy instead of standalone bits. > > > > Specific clients could be created backed by Telepathy, e.g. no need to > > rely on Empathy. > > One of the main points of Sri’s proposal is to get rid of Telepathy. > Its architecture is a burden and e.g. Polari has problems because of > the extra layers that wouldn’t exist if it talked to IRC directly. But isn't that the *point*? We have a framework with plugins for all manner of different protocols, instead of a mess of separate protocol- specific clients each of which can handle only *one*. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 14:00 +0100, Matthew Hodgson wrote: > From memory, the sort of modern features which Matrix has which the API > doesn't handle include: > > * Infinite scrollback serverside history > * Synced history across multiple devices > * Server side search > * Server side notification settings > * Read receipts > * Read-up-to markers > * Multiway voip > * Promoting 1:1s to group chats and vice versa > * Native end-to-end encryption (verifying keys, devices, sharing keys, etc) > * Encrypted file transfers > * Redacted msgs > > And upcoming shortly: > * Reactions / upvotes / downvotes > * Editable msgs > * Pinned messages > * Threading Matrix isn't the only protocol that supports many of those. I'm no fan of Telepathy, certainly — the complete lack of error reporting was what caused me to ditch it and stick with Pidgin for corporate Lync users. When users are completely unaware that they aren't reachable on IM, or why, that's a total UX fail. But I still think we're better off with a *generic* framework, even if we have to drag it into the 21st century, than tying ourselves into a single protocol. Of course if you want to go and make a lovely shiny UI for your single protocol, nobody should dissuade you from that. But to talk about it as a "replacement for Telepathy" doesn't make sense to me. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Fri, 2016-06-10 at 11:47 +0100, David Woodhouse wrote:
>
> If the GtkFileChooser would just allow us to use it *without* its own
> GtkPlacesSidebar, that would probably suffice...
Ahem...
gtk_widget_hide(
/* GtkPlacesSidebar */ gtk_container_get_children(
/* GtkHPaned */ gtk_container_get_children(
/* GtkBox */ gtk_container_get_children(my_file_chooser) -> data
) -> data
) -> data
);
(Yeah, I know. Nasty proof-of-concept hack. Really nasty.)
This actually kind of works — we can place our own GtkPlacesSidebar
*next* to the 'hacked' GtkFileChooser, and we could theoretically sync
the settings of that one into the 'hidden' one in the GtkFileChooser,
to make it look like the real one.
However, the plan falls down we can't actually add our own non-file
locations to a GtkPlacesSidebar. This just doesn't do anything:
gtk_places_sidebar_add_shortcut(self->page1_visible_sidebar,
g_file_new_for_uri("pkcs11:..."));
If we do want to show the 'foreign' locations like PKCS#11 tokens in
the GtkPlacesSidebar — whether it's "properly" with the co-operation of
the GtkFileChooser, or whether it's done externally — we'd want to
resolve that.
For the time being I suspect unless anyone comes up with any bright
ideas, we might just stick with a separate list on the left-hand side
with all the tokens and 'File system', as the ASCII art in my previous
email showed. We'll leave fixing that as an exercise for a later date.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Fri, 2016-06-10 at 06:35 -0400, Nikos Mavrogiannopoulos wrote: > Only a nitpick. "Choose from PKCS#11" is very cryptic for users. I don't > expect from someone not working in security to understand what is this > about. "Choose from smart card" is something more approachable. Except it isn't correct either. Since 'smart card' then includes such locations as GNOME Keyring, and the user's NSS database. Seriously, the *good* way to do this from the UX point of view is just to make the PKCS#11 tokens show up as locations/shortcuts in the chooser, alongside the various directories. That's what you had in the design study: https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 The only problem with this is that it's hard to expose the internals of the GtkFileChooser to allow us to 'take over' the internal browse_files_stack and display our own list of objects within the token — which we need because it needs to look like the Seahorse display in the main pane of http://david.woodhou.se/seahorse.png and the 'file browser' doesn't cut it. And obviously we don't want to use something *other* than a GtkFileChooser for the case where the user *is* actually choosing files; that would be horrid too. If we can't fix this to be like the mockup, maybe the least-bad option is to have two separate 'places sidebars' side by side. The first isn't really a GtkPlacesSidebar; it's a lit of all the PKCS#11 tokens PLUS 'File system'. And then when it's selected, the GtkFileChooser with its own GtkPlacesSidebar is shown next to it. So it's... - | PIV_II | Recent | Gnome2 Key Storage | Home | Gemalto | Documents | Entersafe | Downloads | | ... |→File system← | | | That is still marginally confusing — users will ask why can't they all be in the *same* list instead of having to select 'File system' first? But at least it isn't as bad as our current hack. If the GtkFileChooser would just allow us to use it *without* its own GtkPlacesSidebar, that would probably suffice... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Wed, 2016-06-08 at 21:48 -0500, Federico Mena Quintero wrote: > On Wed, 2016-05-11 at 13:08 +0100, David Woodhouse wrote: > > Tyagi is working on a GSoC project this year, implementing a > > certificate chooser which will probably live in the GCR library. > > I would love to have exactly this thing available for use, for example, > from gtk-vnc and vinagre. > > Right now gtk-vnc assumes that the user will put certs and keys in some > hardcoded locations. The code more or less allows for a scheme where > the user would be prompted for them instead; I'd love to have a good API > to call there. Thanks, Federico. I'd be very grateful if you could join us on #keyring and also check out Tyagi's current work: https://github.com/tyagi-prashant/gcr The new dialog can be tested by running ./gcr-certificate-chooser-test after building GCR. Aside from the request for overall design assistance as discussed, we could also do with some help with the details — just things like when we select a certificate and its preview is shown, everything in the dialog is jumping around as things change size. Those would probably be trivial for you to help with, but neither Tyagi nor I are particularly familiar with the intricate details of how to lay things out properly. If you could help with that, it would be much appreciated! -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Mon, 2016-06-06 at 13:43 +0200, Bastien Nocera wrote: > As nobody has replied, and you asked me to look at the mail, here it > is. Given the long mail and the incredibly specific application of it, > it's unsurprising that there were no answers, and I'll try to explain > why. Thanks, Bastien. I've created a page at https://wiki.gnome.org/Design/OS/CertSelection for this. To keep things simple I've reduced the scope — from the overall "cert + key chooser wizard" flow (which is fairly uncontentious) to just the internal widget which gets used twice to choose *an* object. That's the part we really need help with. The design used in the Red Hat user study was based on a file chooser, with additional 'shortcuts' in the places_sidebar for the PKCS#11 tokens. It seems quite intuitive for the user, and could be made to work well: https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 The problem is that this is non-trivial to implement without access to internals of the GtkFileChooser widget, and there is understandable resistance to providing that. (As a straw man proposal, we can *already* add shortcuts with 'pkcs11:' URIs, so one way we could implement this is by just adding a way to register an widget to live in the browse_files_stack for a specific URI protocol. So 'file:' is built-in, and you can add others. You might even pretend this is a cleanup and handle things like 'Other Locations' that way instead of with special cases in the main code). I've even considered a hack where I register the additional shortcuts for the PKCS#11 tokens, but when they're selected I flip *away* from the GtkFileChooser (which can't handle them) to something else which looks identical to it — with a shadow of the same places_sidebar, but with the Seahorse-like PKCS#11 object browser in the middle. And when the user selects a file shortcut again, we flip back to the real GtkFileChooser. But... ick :) So for now we've side-stepped the issue by having explicit buttons for the user to press for 'Choose from file' vs. 'Choose from PKCS#11'. Once we've finished the cosmetics, we end up with something which is basically the same as our "ideal" idea above — it's just that the location pane can only show file locations *or* PKCS#11 locations at any one time, and you have to "change modes" to flip between them. It seems hard to justify that from the design/UX point of view; only from the "oh, it's too hard to do it nicely" point of view. It's that conflict I'd appreciate help resolving. If anyone can come up with a design idea that *doesn't* involve "nasty hacks" to the file chooser, that would be great. I'd also settle for a consensus from the design side that "we're in this to make it work nicely for the users, not to make life easy for the implementers. Just get on with it" :) Perhaps a slightly less intrusive request for GtkFileChooser is "let us hide this places_sidebar". Then I can put my *own* places_sidebar next to it and I *can* flip to a more appropriate object chooser when it's not a file shortcut that's selected? Thanks! -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: about certificates
ppose we do that. If it's an input request *within* the dialog, which I think I'd prefer, then I think our 'almost done' flows should jump into the key-selection page of the wizard, with the appropriate file already selected and asking for its passphrase. Or for PKCS#11, as if the 'unlock me' button has been pressed, and asking for the PIN. And *then* automatically selecting the key in question, if we find it there. Or leaving the user to go navigating to find a key, if not. But again, UX input most welcome... -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Design help requested: Certificate Chooser UI.
ome. As noted, I'm not really keen on "choose file vs. pkcs#11 first". But if we really can't come up with anything better, I suppose we can tolerate that. Fundamentally, all we *really* care about is that there should be a coherent UI for everywhere that we want users to select their personal certificates, and that it should support all the various file types as well as PKCS#11. We'd like the user experience to be as good as possible, of course, but in some ways that can be improved later and is secondary to the "what API does the GcrCertificateChooser offer to its users" question, and to making those potential users actually *use* it. Thanks for reading this far, and for any feedback you can offer! -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ Nikos, the reports were only sent in private email, is it OK to attach the PDFs to the GNOME bug please? smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
On Tue, 2015-07-21 at 03:11 +0100, Alberto Ruiz wrote: Another problem I didn't mention which is that sometime the checkout dir makes make go bonkers at some point even with jhbuild build -fac. It is quite often that I update my jhbuild setup after ages of not touching it and I have to basically rm -rf * git reset - -hard and configure again to get the build going again. Given how long it takes to jhbuild everything this is another extremely annoying point that we can't ensure won't hit people. You can't leave the thing building and go make a coffee, you have to work for the automation system instead of the other way around. It is really a disaster if you ask me that we enforce this on every GSoC student :/ Perhaps the ideal solution would be to decouple the dependencies. When I'm trying to fix up some mail protocol back end in Evolution, I really *shouldn't* need to upgrade my entire system to the very latest glib/gtk+ and then upgrade a whole bunch of *applications* which for some reason don't work with the new libraries. In this thread we're talking about tooling to *help* me set up a container with that full set of upgraded stuff, but we seem to be missing the point that in an ideal world I shouldn't need it at all. (It doesn't help that we don't have symbol versioning, so the distro packaging has a lot of dependencies wrong, of course. So just running 'dnf --releasever=rawhide update gnome-foo' tends to break.) I often actually find myself testing on the *stable* branch of evolution-data-server, then committing blindly to master. Which is entirely the wrong way round. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Questions about the migration from GConf to GSettings/DConf
Hi Milan,
Thanks for your comprehensive response.
On Mon, 2015-07-20 at 09:04 +0200, Milan Crha wrote:
Briefly grepping the evolution-activesync code, the keys being read
from the GConf look like:
/apps/activesyncd/accounts/email/key1
/apps/activesyncd/accounts/email/key2
...
so you can have a relocatable schema with { key1, key2, ... } and
attach it under /apps/activesyncd/accounts/email. That feels
pretty
straightforward, and if I understand your text properly then you know
it. The thing you face is to know the list of configured accounts.
I would create a 'list' key with a list of known accounts in
/apps/activesyncd/accounts/, which will contain the email of each
configured accounts, and an existing path in GSettings. I saw this
approach being used in another project, I think it was gtk+.
That sounds like a good solution to me; thanks.
. I don't have the perfect solution yet, so I'm here to see if
anyone could help me.
The evolution(-data-server) also used to store its account settings
into GConf, but then moved away from that idea and instead of migrating
account settings into GSettings it uses its own ESourceRegistry. You
can create tree of ESource-s there, each can have its own extension,
where it stores its data. Maybe it would work better than the
GSettings. See how evolution-ews stores its settings on an ESource for
an example (it uses an ESourceCollection for the parent ESource).
Currently, the activesyncd dæmon is independent of Evolution. It
provides a DBus API which is used both from Evolution (for email), and
from SyncEvolution (for contacts/calendar).
So I'm a little reluctant to make it depend on ESource for
configuration.
Alternatively, maybe, create your own API on top of a GKeyFile and
store the account information in it?
Perhaps. I note GOA does something like this for its account storage.
But I think I like your first option better. Thanks again.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
On Wed, 2015-02-11 at 21:26 +, Simon McVittie wrote: On 11/02/15 21:10, Jasper St. Pierre wrote: Another example: for some odd reason, GLocalFileInputStream isn't a pollable output stream (I assume you mean GLocalFileOutputStream.) Why was this done? I don't know. AIUI, because all Unix kernels treat local I/O as arbitrarily fast, hence local files (which might in fact be NFS-mounted from another continent) are not usefully pollable. It doesn't have to NFS-mounted to be slow. The crappy SSD in this laptop also sometimes gets itself into a state where writes are *extremely* slow, and you really notice the apps which are writing to local files from their main loop. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze break request for evolution-data-server (3.12)
I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ Specifically commits a523ac27, bd843434, f98caca8, 581c32aa. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sun, 2014-08-03 at 23:18 +0200, Maciej Piechotka wrote: My guess would be to do it in 'Linux' way and avoid multiply merge commits would be to push the i18n to separate branch and make the maintainer, though I would imagine to be much more complicated for our purposes. Linux is probably not the best comparison because Linux has a single person who is able to push to the master upstream tree. There is *no* way to get your code into that except for Linus to pull it. So you have to have a labelled tree or branch somewhere that he can reference by its URI. But there are plenty of other things which *do* have multiple committers all actively pushing to the same tree. There's no need for separate branches other than the tip of my working tree. It really is just oh, someone else pushed something while I was working. I'll pull that, handle any merge that's required if it isn't entirely automatic, retest as necessary and push again. -- After some digging about usage of git in Linx: LWN article http://lwn.net/Articles/328436/ - Linus does not tell developers not to use it [rebasing]; in fact, he encourages it sometimes., On the other hand, private history can be rebased at will - and it probably should be.. Original Linus post http://lwn.net/Articles/328438/ - So you can go wild on the git rebase thing on it, Keep your own history readable Note that I'm not saying rebasing should be *banned* either. It's a useful tool and I do it all the time. But we shouldn't *force* people to rebase, especially not with commit hooks which block merge commits. If we didn't do that then the whole problem being discussed in this thread wouldn't exist. You could still have a policy of rebase whenever you can because... er, well I don't actually know why, but whatever. As long as you allow normal git usage in the cases such as $SUBJECT where enforced-rebase is causing a real problem. So just dropping the commit-hook, and keeping the same policy but just applying it a little more flexibly, should be ideal. Or perhaps if people really insist, you could even keep the commit-hook but make a special case in it to permit merge commits where one side of the tree only touches the po/ directory. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Mon, 2014-08-04 at 09:38 -0400, Dan Winship wrote: On 08/03/2014 03:38 PM, David Woodhouse wrote: - Make a whole bunch of changes all at once, some of which are related to X, some to Y, some to Z, and some to more than one of them, and without any indication of which changes relate to which commit so no one in the future will ever be able to figure it out ha ha ha. Which sucks. So I'll stick with rebasing, thanks. That is so far from the normal experience of using git as intended, that I don't quite recognise it. How else is a merge commit going to look? If you have more than one commit on your branch, and more than one conflict with master, and you only get one commit to fix it all up, then how can you avoid having that one commit include fixes that are unrelated to one another? (Sure, if you don't have any conflicts, then the merge commit will be empty and confusion-free, but in that case you could have rebased without conflicts too, so the argument about accidentally creating bugs while rebasing doesn't apply.) There are multiple options here. First of all, you *can* rebase if you want to. I don't think anybody objects to that; only to the *forced* rebasing. But let's say you don't want to rebase, because you really do want to preserve the original context and the validity of the original testing — perhaps other people had tested it for you in esoteric environments. If upstream has done X, Y and Z since you started your work and *all* of them interact non-trivially with what you've done, then rather than pulling today's upstream in one go, you could first pull it as of commit X, resolve conflicts and retest, then pull Y, repeat, and finally do the same for Z. Of course, if X, Y and Z are all inter-related then that might actually be a bit more work than doing it in one go — so you might *not* want to do that. But it's *one* of the options. I'm not trying to take away your options, of which rebasing is sometimes a perfectly valid one. I'm pointing out that this thread only exists because one of the useful options (i.e. *not* rebasing) *has* been taken away. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 08/02/2014 10:38 AM, David Woodhouse wrote: If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Except that this correct version of history looks like this: - Implement X - Implement Y - Implement Z - Make a whole bunch of changes all at once, some of which are related to X, some to Y, some to Z, and some to more than one of them, and without any indication of which changes relate to which commit so no one in the future will ever be able to figure it out ha ha ha. Which sucks. So I'll stick with rebasing, thanks. That is so far from the normal experience of using git as intended, that I don't quite recognise it. It sounds like you've had a bad experience of someone doing something truly bizarre and ill-advised, and it's put you off doing things *correctly* for ever more. Much like the libxml2 insanity with quantum symbol versioning seems to have put people off using *that* properly. Or indeed at all. But I wasn't necessarily expecting the don't use git properly policy to be changed - it's just that nobody seemed to be acknowledging the elephant in the room in this thread, which was that the whole problem being discussed is an artificial one purely caused by that policy. So I felt it appropriate to make sure it was mentioned. -- dwmw2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. You shouldn't need to create a branch for this. What we're talking about here is an utterly normal and everyday part of the git workflow — not specific to releases and translations. Any time you've done some work locally and it's time to push it upstream, you may find that someone else has pushed something before you. The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. There's nothing to see here; this whole thread doesn't exist. There is no problem. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. Right. You have correctly identified the root cause of the problem. We shouldn't be advising people as a matter of course *not* to use the version control system correctly in the manner in which it was designed. This mentality of rebasing for no better reason than because we like straight lines isn't just an issue in the specific case discussed here. It also causes the loss of accurate history in other cases, which can cause problems. It's relatively rare, but it does happen that two concurrent patches can conflict with each other. I could do some work in my local tree which is entirely correct and functional, but by the time I've finished testing and I go to push it upstream, someone else has pushed something which subtly breaks my work. If I rebase, it is just human nature that I'm not going to retest every intermediate commit of the rebased version as carefully as I retested the original, and it's quite possible that I'll end up pushing a commit which in some circumstances *never* worked. If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Whereas if I rebase and rewrite history to make it look like I just committed something that *never* worked, sorting that out later is *much* harder. We really ought to abandon this idea that we prefer to have a linear git history. It might be simpler that way, but it's wrong, and in the cases that *matter* it actually makes things harder. And the cases that don't matter... don't matter. Unless you have some kind of OCD about straight lines. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On Fri, 2013-10-11 at 10:25 +0100, Ross Burton wrote: Or be a better alternative to Empathy for rooms, leaving Empathy (or eventually, Contacts + Shell, I guess) for IM. That seems like confusing balkanisation to me. So if I'm having a conversation in an IRC channel with someone, and we decide to take it *off* the channel to private messages, it suddenly ends up in a different app altogether? Or would the differentiation be on the *protocol* it uses? Which doesn't sound like a very user-friendly idea either. And many IM protocols actually support group chats or meetings too... And if there's an IRC channel with only two people in, what then? :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On Fri, 2013-10-11 at 10:39 +0100, Nick Glynn wrote: So there's going to be Empathy, Chat and Polari? Don't forget that some stuff appears in a notification pop-up instead, so that's a fourth option. :) And then there's a *separate* tool I have to fire up to check whether a given account is actually *connected* or not, since the standard Empathy/Shell UIs don't think that's important to show me. So that's five... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On Fri, 2013-10-11 at 11:18 +0100, Allan Day wrote: The usage patterns for IRC are different from regular IM (passive presence in many always on channels vs. active participation in a smaller number of temporally specific conversations). You can't support both with the same UI (I know, I've tried to design such a thing). I'm not so sure they're really different. I have a passive presence on my corporate IM system, always indicating my availability (available/busy/away/etc.). And it's very likely to be 'always on' these days, since I can also receive voice calls from the PSTN when I'm connected to it. And there are obviously the small number of temporally specific conversations that you mention. But all that *also* describes my IRC usage. Yeah, it's always on, and it can indicate my availability, and I'll have a number of short-lived conversations. To me, there isn't a clear distinction between one and the other. There's a broad *spectrum* of communication, and even 'group chat' can end up including meetings, with audio conferencing, desktop sharing and all the other stuff that can bring. But then, so can 1:1 messaging. I worry about trying to draw clear lines between types of usage and design *different* clients for each. Because there's a lot that might then fall through the cracks. OK, so it isn't necessarily that easy to do one tool to solve all use cases either — but at least if we take that approach there is no need for the user to learn how we've drawn our arbitrary¹ distinctions between use cases and which tool to use for which. And we'll *have* to bear in mind the fact that there is a *spectrum* of usage which we have to encompass, rather than each separate tool focusing on only a tiny part of it. -- dwmw2 ¹ to the user. Probably. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On Fri, 2013-10-11 at 13:45 +0100, Allan Day wrote: The same as it does now for XChat or some other IRC client? Fair enough. If it's just another IRC client and isn't attempting to be more, and isn't a core app, that makes sense. I was confused because people seemed to be suggesting that it would be more. And partly, perhaps, because I really *want* to believe that someone's working on replacing Empathy :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 features: better integration with Facebook and Windows Live
On Mon, 2013-10-07 at 12:22 +, Debarshi Ray wrote: - https://wiki.gnome.org/ThreePointEleven/Features/WindowLiveMail In short, you would be able to ... use your Windows Live (outlook.com, live.com, hotmail.com) email from Evolution. Shouldn't we be using EWS for at least some of those, rather than IMAP+SMTP? -- dwmw2 signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 features: better integration with Facebook and Windows Live
On Mon, 2013-10-07 at 13:02 +, Debarshi Ray wrote: If you look at http://blogs.office.com/b/microsoft-outlook/archive/2013/09/12/outlook-com-now-with-imap.aspx (which is linked from the feature page), then the other alternative is EAS or Exchange ActiveSync [1] not EWS. Those are the protocols they've *added* to support mobile access, AFAICT. But they *already* supported EWS natively, and that is the protocol they support best. EWS is a much richer protocol than ActiveSync, and Microsoft's IMAP implementations have always been broken. Seriously, if EWS is available then just use it. Although I *would* like to see Evolution's ActiveSync support get a higher profile :) -- dwmw2 signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, dumbing down Slashdotted
On Tue, 2013-09-24 at 12:15 -0400, Hashem Nasarat wrote: tnks for all the job you are doing, it's really appreciate, I can say GNOME 3 is so easy to use that also my grandmother can use it!! Please don't be disparaging to grandmothers who use GNOME. http://geekfeminism.wikia.com/wiki/So_simple,_your_mother_could_do_it He's not. Just like I'm not being disparaging to all fathers who use GNOME, when I say almost the same thing except my father can use it. I never tried to get my grandmother to use GNOME. I *do* get my father to use GNOME. And it's a *painful* experience :) If you want to make rampant generalisations, that's fine. But don't then blame *me*, or Tglman, for the inferences you draw that weren't necessarily implied. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, dumbing down Slashdotted
On Tue, 2013-09-24 at 20:00 +0100, Emmanuele Bassi wrote: I think ”have not been publicised” is the exact pain point of design process. Wider community has no insight into design until it's finished. And it's too late for a meaningful input at that point. you need a design first, if you want to comment on it. also, to dispel a myth: no design is finished. ever. there is always time to fix things. I think the truth really lies somewhere in the middle. Or rather, it depends on the *type* of feedback. Yes, there's always time to tweak things after the design has been implemented. But if you're trying to have input to the *core* of the design, that's likely to be hard to change by then. Now does seem to be about the right time to scream you will take the middle-click paste from my cold dead fingers. Later, after the initial beta release, would be the time to say oh, that horrid thing you've done that I never use and keep accidentally getting when I try to paste, and makes me want to throw my mouse out the window? Let's make it green instead of blue. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Tue, 2013-07-09 at 12:55 +0200, bugs wrote: Well. That sounds pretty much like the awful implemetations of Unity (Ubuntu) and MacOS (Apple). As far as I understand the Application-Menu should not replace regular menues, but instead offer a addition to to regular menues, with only some concise items (Open, Preferences, Help, About, Exit not not much more). That doesn't seem to be the case with empathy, at least. I couldn't find *any* way to add a contact there, until I filed a bug and was told that the only way to do that was hiding on the opposite corner of the screen. Should I file a bug? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Sun, 2013-07-07 at 14:10 +0200, bugs wrote: Or did I miss the obvious solution? Well, there's always the revolutionary idea of putting the application's menu somewhere near the application, rather than two feet away at the opposite corner of the screen. But if hiding it somewhere a long way away from the app is actually considered to be a *good* thing¹, then why would we *not* want to put it on a different screen? Surely that would be even *more* fun for the user to find, so it's even *better* than the original menu elsewhere implementation on a single screen was? -- dwmw2 ¹ I didn't follow the logic here, but maybe we decided that users were using menus too much so we wanted to make them harder to use, in order to encourage different workflows which were actually *within* the application? smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Mon, 2013-07-08 at 12:53 -0500, Michael Catanzaro wrote: I really hope we can agree on and enforce a solution that provides consistency between apps that retain traditional menubars. Maybe it'd be easier to agree on duplicating the items than moving them. That would certainly alleviate my major concern, which is that the affected menu options are now two feet *away* from the application in some cases. Even if the user discovers them there, it's still a distinctly suboptimal workflow. To move the mouse that far, I have to move it from one corner of the clear area of desk which serves as its 'mat' to the opposite corner, then pick it up and place it back where it started... about four times. That is not a useful in-application workflow. Having the menu elsewhere items actually available *in* the application's window too would be a dramatic improvement. -- dwmw2 signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Thu, 2013-07-04 at 16:18 -0500, Michael Catanzaro wrote: I haven't seen an app menu (gmenu) discussion in quite some time, which is a bit surprising as more apps add them. 3.10 will be the fourth release featuring app menus, and by now most GNOME applications have one. But the only information on the GNOME wiki seems to have been written for GNOME 3.4, and there seem to be some issues and inconsistencies with the implementation throughout the project. I've been using GNOME all that time and I'd never noticed them. This is the one in the top panel which, with focus-follows-mouse, means I have to *quickly* move my mouse to the top of the screen from the tiny empathy buddies window — without it resting for a moment over any other window, otherwise *that* application's menu ends up in the panel by the time I get there? That's great fun with a trackpad and a large screen, where it might take two strokes of the finger to get from one corner of the screen to the other. And only *then* can I find the 'add contact' option, that I expected to find *in* the empathy application over there about 25 inches away at the bottom right corner of my screen? I actually filed a bug because I couldn't *find* the 'add contact' option. And then didn't understand what I was being told, when I was told it was in the 'GNOME Shell context menu'. It had to be explained to me in graphic detail. A stunningly unhelpful development, it seems to me. I would strongly resist the suggestion that Evolution should gain this monstrosity, especially if it's unconditional. -- dwmw2 signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ 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.
Focus-follows-mouse makes it worse (especially when it's a trackpad, and
a large screen, and a small application like empathy which happens to be
on the *other* side of the screen for where its bizarrely detached menu
now lives.
But it's a fairly horrid user experience even without that. I still
didn't even know it was *there* because it was miles away from where I
was actually *looking*, when I was using the application.
Are we also deprecating non-maximised windows? Perhaps that might make
the 'app menu is not in your app' thing make sense?
In the meanwhile, you can move the menu back inside the window itself:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/README.xsettings
Ah, that's really useful; thanks. For those playing along at home,
that's:
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides \
{ 'Gtk/ShellShowsAppMenu': 0 }
... and then restart both gnome-settings-daemon and gnome-shell, it
seems.
Well, it'd be *more* useful if I hadn't given up on empathy and the
gnome-shell telepathy integration already and gone back to using pidgin
because it actually works, and it actually *shows* me when it isn't
connected, rather than trying to avoid confusing me with those scary
technical details like the fact that I cannot be reached by my
colleagues.
But although empathy is the only application in which I'd discovered
this problematic menu elsewhere, I'll leave it disabled just in case
some *other* applications now regain some missing functionality in their
*own* window, where I naturally expect it to be.
Thanks.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.10 Feature: Integrate Zimbra in GNOME
On Wed, 2013-04-10 at 10:00 +0200, Juanjo Marin wrote: Zimbra and Alfresco support are good features to promote GNOME as corporate Desktop. ActiveSync too. We have Evolution mail support for ActiveSync, but the only user of the GNOME ActiveSync client for calendar and addressbook is SyncEvolution. I'd love to see 'native' EDS clients for those too. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enterprise Active Directory support question
On Mon, 2013-02-11 at 08:29 +0100, Stef Walter wrote: In GNOME 3.6 Enterprise logins was introduced. This feature is very attractive for enterprise deployments because it makes possible to add GNOME workstations into Windows networks with Active Directory. My understanding of this feature is that it only enables users to log on their GNOME workstations, so it doesn't enable them to use the shared folders or network printers of their domains without login again for every shared resource. Well it should do those things. I know that the shared folders does work. For example, we tested it in Fedora: And automatic login with NTLM, and keeping a Kerberos TGT valid, are both mostly solved problems too. Although we do need to dust that work off and merge it. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
First release of Evolution-ActiveSync (v0.92) for Evolution 3.4
It's syncing to download.gnome.org slowly, but for now is available at ftp://ftp.infradead.org/pub/activesyncd/evolution-activesync-0.92.tar.xz ftp://ftp.infradead.org/pub/activesyncd/evolution-activesync-0.92.tar.xz.asc This is now updated to work with Evolution 3.4. As before, this package contains the core dæmon for communication with the ActiveSync server, as well as a Camel back end and Evolution EPlugin for configuring it. SyncEvolution modules for calendar and addressbook synchronisation are part of the SyncEvolution repository. We don't have 'direct' Evolution calendar and addressbook back ends yet, although that would be nice. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Exchange support in Online Accounts (or GOA)
On Tue, 2012-04-24 at 09:29 +0200, Tomasz Torcz wrote: Why Web Services and not MAPI? Web Services sounds like going through some fragile abstraction layer, MAPI seems more direct. EWS is the protocol they say they'll support going forward; they've been saying MAPI is obsolete (or at least obsolescent) since Exchange 2007. EWS is also simpler to support, as it's just SOAP and doesn't pull in a bunch of bleeding-edge Samba stuff to support a complex binary protocol. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
On Wed, 2012-04-18 at 17:55 -0500, Federico Mena Quintero wrote: I wonder how people who hack on core Gnome do it on a day to day basis. A lot of the time, I do it by finding cases where a dependency on some bleeding-edge Gnome module is *entirely* gratuitous, and just changing configure.ac to fix that bug. To pick an example, my network-manager-openconnect build tree almost *always* contains a local change along the lines of... --- a/configure.ac +++ b/configure.ac @@ -96,10 +96,10 @@ if test x$with_gnome != xno; then fi PKG_CHECK_MODULES(NM, - NetworkManager = 0.9.4 - libnm-util = 0.9.4 - libnm-glib = 0.9.4 - libnm-glib-vpn = 0.9.4) + NetworkManager = 0.9.1 + libnm-util = 0.9.1 + libnm-glib = 0.9.1 + libnm-glib-vpn = 0.9.1) AC_SUBST(NM_CFLAGS) AC_SUBST(NM_LIBS) I *wish* we'd use version requirements properly, rather than bumping the requirement just because there *happens* to be a new version available. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
ActiveSync support for Evolution
Since I've been using this in anger for my company email for the last few months, and I haven't had cause to touch the code since the beginning of December... I suppose it's about time I pulled my finger out, called it a release, and tried to import it into GNOME. So... http://git.gnome.org/browse/evolution-activesync/ git://git.gnome.org/evolution-activesync For those who weren't aware: this is a basic implementation of the ActiveSync protocol, in a standalone dæmon which is accessed by DBus. Clients of this dæmon include a Camel provider which is included in the git repository, and a SyncEvolution plugin for calendar/contacts synchronisation, which is shipped with SyncEvolution itself. We could add e-d-s back ends for direct access to calendar/contacts too. The Camel provider supports Evolution 3.0 and 3.2; I've made a start at updating it to 3.4 but won't finish it before I disappear for a week, starting tomorrow. If any kind person feels like copying most of Milan's commits f7dd1cd2 and 8cf26212 from evolution-ews, that would be much appreciated. Otherwise I'll get to it when I get back. -- dwmw2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
