Re: gnome-control-center/panels/wacom - button mapping panel
On 29/04/13 01:33, Przemo Firszt wrote: I hope to do some work on wacom tablet button mapping in gnome control center. First mockup of new individual button mapping panel: http://firszt.eu/wacom-icons/mockup_of_wacom__button_mapping_panel.png Roadmap: 1. Change existing panel to simple button list + add a new panel activated after clicking on a button (mockup) This would mean we're three panels deep to assign a button - not sure that's a good thing. I don't like the tab approach much either if it's only going to be one button anyway, this should be window title or similar I think using the svg files libwacom provides would be a good approach, display the tablet and then let the user click on the button to be assigned - so they don't have to care about the button numbers either. 2. First version would include only existing or already coded features - single keystroke, on screen help, monitor switch, OLED labels matching mapping. The last one is waiting for review on bugzilla. 3. Add option to edit label i.e. to show "Save" instead of "Ctrl-S" on tablet just as a warning, this has the potential to be confusing. "Save" is not the same as Ctrl-S and we should not confuse the two. I understand that the user wants save, but if you e.g. assign Ctrl+C you'll copy in one app and cancel something in another app. though I guess we'll have to live with that until we get semantic events. other than that I like it, it looks more professional than the current list IMO. Cheers, Peter 4. Add option to select an icon instead of label. 5. Implement keystroke sequences. Please let me know what do you think about it. P.S. Sorry for the noise if you got this email twice ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Collaboration on standard Wayland protocol extensions
On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote:
> Greetings! I am the maintainer of the Sway Wayland compositor.
>
> http://swaywm.org
>
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
>
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
>
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
> does it want to draw its own decorations, etc)
> - Input device configuration
a comment on the last point: input device configuration is either extremely
simple ("I want tapping enabled") or complex ("This device needs feature A
when condition B is met"). There is very little middle ground.
as a result, you either have some generic protocol that won't meet the niche
cases or you have a complex protocol that covers all the niche cases but
ends up being just a shim between the underlying implementation and the
compositor. Such a layer provides very little benefit but restricts what the
compositor can add in the future. It's not a good idea, imo.
Cheers,
Peter
>
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
>
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Collaboration on standard Wayland protocol extensions
On Thu, Mar 31, 2016 at 05:37:10PM +0200, Benoit Gschwind wrote: > Hello Drew, > > After reading the thread stream, I think there is two mixed questions in > your email that is missleading. And most reply try to address both in > one reply. I thing Daniel get the point (if I understood him well). > > I read the two following questions: > > [1] As almost all compositor will need the following features: > - Screen capture > - Output configuration > - More detailed surface roles (should it be floating, is it a modal, > does it want to draw its own decorations, etc) > - Input device configuration. > > It would be nice if we go around a table to define some shared protocol. > For those interested I will start writing an XML spec. you are welcome > to contribute. I'm mostly talking about the input device configuration here but an XML is the wrong place to start, imo. As I said above, it won't add anything much and you still have to do the implementation everywhere. The only meaningful thing you can do is write a library that compositors *want* to use that reads the configuration items from some magic place and applies them to the libinput device. and for those that must be handled in the compostior (key remappings, for example) you'll essentially end up writing a libcompositorinput. but now you're quite close to internal compositor semantics so making this a generic thing is not going to be trivial. Cheers, Peter > > [2] This features are mandatory and should be in the core protocol. > > > If my reading is correct, I reply to [1]: > > I'm in, I would like to avoid implements tools that setup screen layout, > keymaping and screen capture. Thus having a protocol to handle those > case is welcome. From my point of view of WM developer (in opposition of > DE developer) > > > For [2], I suggest that you starting with not-adopted protocol > specification and if they gather enough approval, you try to push it as > _optionnal_ standard protocol. By optionnal I mean the compositor > developer can choose to implement it or not. by standard I mean if a > developer want implement those feature we strongly encouraged developper > to use them instead of providing a new one. > > Best regards. > > -- > Benoit (blocage) Gschwind > > Le 27/03/2016 22:34, Drew DeVault a écrit : > > Greetings! I am the maintainer of the Sway Wayland compositor. > > > > http://swaywm.org > > > > It's almost the Year of Wayland on the Desktop(tm), and I have > > reached out to each of the projects this message is addressed to (GNOME, > > Kwin, and wayland-devel) to collaborate on some shared protocol > > extensions for doing a handful of common tasks such as display > > configuration and taking screenshots. Life will be much easier for > > projects like ffmpeg and imagemagick if they don't have to implement > > compositor-specific code for capturing the screen! > > > > I want to start by establishing the requirements for these protocols. > > Broadly speaking, I am looking to create protocols for the following > > use-cases: > > > > - Screen capture > > - Output configuration > > - More detailed surface roles (should it be floating, is it a modal, > > does it want to draw its own decorations, etc) > > - Input device configuration > > > > I think that these are the core protocols necessary for > > cross-compositor compatability and to support most existing tools for > > X11 like ffmpeg. Considering the security goals of Wayland, it will also > > likely be necessary to implement some kind of protocol for requesting > > and granting sensitive permissions to clients. > > > > How does this list look? What sorts of concerns do you guys have with > > respect to what features each protocol needs to support? Have I missed > > any major protocols that we'll have to work on? Once we have a good list > > of requirements I'll start writing some XML. > > > > -- > > Drew DeVault > > ___ > > wayland-devel mailing list > > wayland-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > ___ > 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: Some dudes opinion on Ctrl-Tab
On Thu, Oct 13, 2016 at 10:27:43AM +0100, Sam Thursfield wrote:
> On 9/17/16, Daniel Beecham wrote:
> > + All major web browsers (Firefox, Chrome, Edge, Internet Explorer, Opera,
> > Midori and others) use ctrl-tab to switch tab. Neither nor
> > consumes tab in any of these browsers, it's just used to change
> > focus.
>
> Cool, I never realised because those that I use also allow tab
> switching with ctrl+pgup and ctrl+pgdn.
>
> ...
>
> > * The argument of obviousness ("don't make me think", or "great design is
> > invisible")
> >
> > Ctrl-tab is such an ubiquitous binding by now, that users just sort of
> > expect it. I saw a design talk by some designer on google the other day,
> > and she talked about how they'd just plop a UI in front of people and see
> > what they'd do - and then make the UI such that those interactions made
> > sense. Like A/B testing a'la extreme. You want an interface which is
> > obvious, which makes sense, is intuitive, doesn't get in your way. Those
> > are the successful interfaces. ctrl-tab is obvious.
>
> Is your point here that people who've never used a computer before
> will figure out that ctrl-tab switches tabs without any kind of
> instruction, but will not figure out that ctrl-pgup and ctrl-pgdn
> switch tabs unless someone tells them? I find that hard to believe
> without evidence. Maybe I'm missing your point.
I didn't know that...
Cheers,
Peter
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Thu, Apr 27, 2017 at 03:24:24PM +0100, Emmanuele Bassi wrote: > Replying to both Michael's and Iain at the same time, to reduce the > amount of email. > > On 27 April 2017 at 15:04, Michael Catanzaro wrote: > > On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane wrote: > >> > >> As it happens I interacted with this script (in gnome-software) > >> yesterday. I hadn't got a new enough jhbuild - the one I had was trying > >> to call ./configure instead of meson directly. > >> > >> The script AFAICS ignores unknown arguments. In particular, I was > >> interested in passing some --enable/--disable flags to select features > >> but I didn't find out how to do that short of explicitly extending it > >> with those particular options. If you expect distributors to be using > >> this, or if this is interesting for users of the build API, is having > >> some support for ./configure <-> meson_options integration a reasonable > >> request? > > Each module has its own set of options with their own name and > semantics; the build-api only defines a specific subset, so if you > want to have a `configure` script to paper over the Meson switch, you > also get to add the options you want to port over. > > Mostly because if I end up patching this script into Continuous, then > I get to be the one who decides which options get ported over and > which one don't; maintainers of a project are usually best suited at > that. > > For instance, the libinput maintainer has started dropping all > auto-detection checks and now the build relies on specifying all > options; a worthy goal, and I'd actually hope more modules followed > suit. If he also switched to Meson-only, I'd have to write a patch for > Continuous that manually ported over the build options as a > compatibility layer; I would do this only for the options Continuous > supports, though, and it would take me slightly more time than just > copying the file over. I will, but I'll keep the two parallel for at least a release or two. If you need me to add anything specific to keep continuous happy for the time being, let me know. Cheers, Peter > > >> Otherwise, and this is what happens now that I upgraded jhbuild, using > >> meson directly works fine. But if a goal of this is to smooth the > >> transition path and avoid a requirement for tooling to be updated, maybe > >> it would be useful. > > Of course. > > > This compatibility issue seems like a very good argument for shipping the > > "compatibility" script in Continuous patches rather than application > > repositories. > > As I said, this takes me (in the absolute simplest case) about 90 > seconds of my life, so I don't mind doing a patch. > > I'd be happier, though, if maintainers that are planning to drop > autotools also dropped me a line so that I don't wake up to a string > of failed builds and then have to figure out whether or not this was a > planned break, or just general CI failure. *Especially* if the > maintainer also fixes the jhbuild moduleset. > > So, I guess the real question is: communicate these changes > beforehand, instead of pushing to master and then going home without > looking at the explosion? > > Ciao, > Emmanuele. > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Fri, Apr 28, 2017 at 10:34:03AM +0100, Richard Hughes wrote: > On 28 April 2017 at 01:00, Peter Hutterer wrote: > > I will, but I'll keep the two parallel for at least a release or two. > > I tried doing this in my projects last cycle and was a bit of a > disaster. Pretty much any committer that added files or changed how > the project was built, broke one of the two systems. Asking people to > test two quite different build systems before sending patches is > raising the bar a little too high and adding confusion. IMHO, etc. Yeah, I can see that. 'fortunately', libinput has a continuos contributor count of approximately 1, so I guess having all contributors test two build systems won't be the biggest issue ;) Cheers, Peter ___ 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 26/4/19 24:56 , mcatanz...@gnome.org wrote: Hard to believe this is a serious discussion that we're actually having. On Thu, Apr 25, 2019 at 7:02 AM, jtojnar--- via desktop-devel-list wrote: On Thu, 25 Apr, 2019 at 11:21 AM, Daniel Playfair Cal via desktop-devel-list wrote: "master/slave" -> "leader/follower" Please note that leader/follower terms are commonly associated with exploitation of people by cults and should be avoided as well. Since it's impossible to tell what the intended tone here is: was this a serious request to avoid the terminology, or a joke intended to make a point? (I'm guessing the later?) I'm a German native speaker and to me the word "leader" has definite negative connotations, for the obvious historical reasons. For some reason the same connotations don't occur where context is available like "thought leader" or "leader of their academic field". Languages/brains are weird. But just "leader" on it's own? Not good. Likewise, "follower" is weird. In a sports context it works, otherwise it has a religious/cult/submissive context. Which is the crux of the matter really: whatever you're going to pick will have different connotations in other languages. Many ESL speakers will primarily think in their own language and substitute the words to English. So if you want to change terminology, I suggest getting a domain expert involved rather than 'randomly' picking something that sounds good to a small set of developers. That's how the original master/slave wording was decided on after all. Cheers, Peter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: one desktop, two people, two keyboards and mice
On Sun, Mar 22, 2020 at 07:08:51PM +, Richard Henwood via desktop-devel-list wrote: > Hi All, > I have a large monitor, and I would like to use my computer with my child. > My vision is for me and my child to have our own keyboards and mice. I > imagine working away on 'my side' of the screen, while they are working on > their side. Occasionally, I will 'reach across' and help them with what > they are working on. As Niels already pointed out, multiseat is the word to look for here. However, the most common documentation on multiseat you will find is for separate sessions on the same host computer. The goal is to save on hardware, not collaboration. If you google for MPX or Multi-Pointer X, that provides what you need and it's been supported in X since 2008 or so. Should be immediately available via: xinput create-master "somename" xinput reattach "my usb mouse name" "somename pointer" xinput reattach "my keyboard name" "somename keyboard" You'll get the various device names from "xinput list", the master device name is whatever you want it to be. however... MPX is a very niche case and not used very often, which means there will be bugs lurking. GTK3 supports it natively to some degree but there are limitations because the whole interaction with the desktop changes and becomes a lot more complicated - and for something that's that niche, surprisingly not everything got rewritten :) The general rule is: while you're interacting in two different X clients, things will probably work, but when you're interacting with the same one, that client will get confused. Unfortunately that also applies to the window manager - moving two windows at the same time won't work. For Wayland compositors - I think setting the ID_SEAT property on the input devices to 'seat1' (default is seat0) should be sufficient to get them into a new wl_seat and thus all of the above. I haven't played with that in a long time though but unlike X, Wayland supports this in the core protocol. Even if it works, expect the same bugs and issues because of it's niche functionality and the massive effort required to actually make this work. Cheers, Peter > I think libinput is part of the solution here. I added two mice it roughly > worked but there are mice cursor artifacts. I guess that GNOME or possibly > Wayland also needs some concept of multiple simultaneous inputs? I am on > an Ubuntu 18.04 distro, so may be things have improved with more recent > releases? > So, in short, does anyone have any pointers or suggestions for me to > follow-up with? > best regards,Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
