Re: gnome-control-center/panels/wacom - button mapping panel
Dnia 2013-04-30, wto o godzinie 15:54 +1000, Peter Hutterer pisze: > 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 agree with both points. I'm still looking for the best option. > 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. True - that's probably the easiest for user. I thought about using the existing osd help, but I don't think it's easily possible. > > 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. Switching based on active application would be another solution (windows is using that approach, most of the time works). Default option will be to generate Ctrl-S for Ctrl-S keystroke, but I want to have an option to override that i.e. for gimp users - it's better to have tools names instead of "P" for paintbrush, "N" for pencil and so on. > other than that I like it, it looks more professional than the current > list IMO. Thanks for your opinion! -- Kind regards, Przemo Firszt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libRSVG development
It is probably more effective to ping Christian on irc (he's chpe on gimpnet) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GnomeGoal proposal: InstalledTests
On Tue, 2013-04-30 at 10:27 -0700, Travis Reitter wrote: > On Fri, 2013-04-26 at 22:47 +0900, Tristan Van Berkom wrote: > > On Fri, Apr 26, 2013 at 9:46 PM, Matthias Clasen > > wrote: > > On Thu, Apr 25, 2013 at 10:45 AM, Colin Walters > > wrote: > > > > > > > >> Do we have (makefile) infrastructure to allow GTests to run > > both > > >> uninstalled (during make *check) and installed? > > > > > > Not at this time; that'd be nice, but I think the jhbuild > > model > > > mostly obviates the need for uninstalled tests, because > > jhbuild by > > > nature is a sandboxed environment independent from the > > underlying > > > system. > > > > > > > > You are not going to get me to buy eagerly into a new > > installed tests > > scheme for glib if it means that I have to give up make check. > > > > > > I just wanted to jump in and mention that, I'd really really like to > > see > > better all around relocatability of modules. > > > > > > Ideally, I'd like to see the following things: > > o Ability to run installed tests, encapsulated in the jhbuild prefix > > > > o Ability to use the same test cases that I use in-tree as installed > > > > tests, hopefully by simply installing my in-tree tests somewhere > > > > (perhaps they would run without some of the custom env vars > > > > that I would use in-tree, but still re-use all the same test > > suites > > > > when installed) > > > > o Overall relocated D-Bus and settings environment > > > > > > > > This last one is a really big deal, there are some really annoying > > things right now, for instance I can in *no way* test GTK+ apps > > > > in a jhbuild shell and use the theme installed in the jhbuild prefix. > > It seems natural that when typing 'jhbuild shell', any processes > > that run should be accessing the settings persisted somewhere > > in /opt/devel... instead I would have to slave my whole system > > just to see what an app looks like with the theme installed > > in /opt/devel. > > This problem applies to a whole classes of Gnome development. I just > lost of a lot of time yesterday trying to set up a development > environment in a VM so I would have a full, graphical session (because > apparently parts of the Shell are what normally start up some EDS > components, so 'jhbuild shell' is insufficient). I still don't have a > working solution here and I've lost track of the times I've tried to > resolve this with existing components without success. > > Any long-term solution needs to be based within a standard VM setup that > most developers (core and third-party) all use (for dog-fooding > purposes). Many developers can get away with just using jhbuild now, but > it's too different from a regular session for other developers. > > I think there was general agreement on this idea in the Gnome Developer > Experience Hackfest in February. We need an SDK that is the official and > de facto standard for first- and third-party Gnome development so we can > all benefit from solutions to our common development problems. > > > GTestDBus has brought us at least part of the way there when > > it comes to D-Bus, but if we run installed tests we'll want to disable > > the relocation of services done by GTestDBus (so that some apps > > and services can interact with other services installed into the > > > > build prefix, instead of running in complete isolation which is > > more appropriate for 'make check'). Perhaps this can be done > > by hardwiring some features directly into GTestDBus, of course > > in this case we still would want to run a separate session bus for > > the jhbuild environment, so that the whole relocated installed > > test suite does not interfere with a real active session. > > When I'm developing, I honestly only care how my new code works when > it's installed. I use build-tree tests to save the time of installing, > starting a new session for the development user (if necessary), etc. The > length of the development cycle between each edit and verifying it is > critical. The difference between a 3s and 1m loop is huge in my > productivity. > > But if a 1-minute loop meant not fighting issues related to build-tree > vs. installed, full graphical session vs. jhbuild session, etc. issues, > I'd very gladly take it. And 1 minute is just an arbitrary number. I'm > sure we could minimize the lag added by installation, session > initiation, etc. In the nearer-term, if we could optimize 'make check' for quick sanity checks (particularly if we could work out minimum dependencies automatically) and run installed tests for a more comprehensive test, I would probably move a fair number of the Folks tests to be installed. That could speed up my development loop quite a bit without too much work and would buy more time to speed up the "comprehensi
Re: New GnomeGoal proposal: InstalledTests
On Fri, 2013-04-26 at 22:47 +0900, Tristan Van Berkom wrote: > On Fri, Apr 26, 2013 at 9:46 PM, Matthias Clasen > wrote: > On Thu, Apr 25, 2013 at 10:45 AM, Colin Walters > wrote: > > > > >> Do we have (makefile) infrastructure to allow GTests to run > both > >> uninstalled (during make *check) and installed? > > > > Not at this time; that'd be nice, but I think the jhbuild > model > > mostly obviates the need for uninstalled tests, because > jhbuild by > > nature is a sandboxed environment independent from the > underlying > > system. > > > > You are not going to get me to buy eagerly into a new > installed tests > scheme for glib if it means that I have to give up make check. > > > I just wanted to jump in and mention that, I'd really really like to > see > better all around relocatability of modules. > > > Ideally, I'd like to see the following things: > o Ability to run installed tests, encapsulated in the jhbuild prefix > > o Ability to use the same test cases that I use in-tree as installed > > tests, hopefully by simply installing my in-tree tests somewhere > > (perhaps they would run without some of the custom env vars > > that I would use in-tree, but still re-use all the same test > suites > > when installed) > > o Overall relocated D-Bus and settings environment > > > > This last one is a really big deal, there are some really annoying > things right now, for instance I can in *no way* test GTK+ apps > > in a jhbuild shell and use the theme installed in the jhbuild prefix. > It seems natural that when typing 'jhbuild shell', any processes > that run should be accessing the settings persisted somewhere > in /opt/devel... instead I would have to slave my whole system > just to see what an app looks like with the theme installed > in /opt/devel. This problem applies to a whole classes of Gnome development. I just lost of a lot of time yesterday trying to set up a development environment in a VM so I would have a full, graphical session (because apparently parts of the Shell are what normally start up some EDS components, so 'jhbuild shell' is insufficient). I still don't have a working solution here and I've lost track of the times I've tried to resolve this with existing components without success. Any long-term solution needs to be based within a standard VM setup that most developers (core and third-party) all use (for dog-fooding purposes). Many developers can get away with just using jhbuild now, but it's too different from a regular session for other developers. I think there was general agreement on this idea in the Gnome Developer Experience Hackfest in February. We need an SDK that is the official and de facto standard for first- and third-party Gnome development so we can all benefit from solutions to our common development problems. > GTestDBus has brought us at least part of the way there when > it comes to D-Bus, but if we run installed tests we'll want to disable > the relocation of services done by GTestDBus (so that some apps > and services can interact with other services installed into the > > build prefix, instead of running in complete isolation which is > more appropriate for 'make check'). Perhaps this can be done > by hardwiring some features directly into GTestDBus, of course > in this case we still would want to run a separate session bus for > the jhbuild environment, so that the whole relocated installed > test suite does not interfere with a real active session. When I'm developing, I honestly only care how my new code works when it's installed. I use build-tree tests to save the time of installing, starting a new session for the development user (if necessary), etc. The length of the development cycle between each edit and verifying it is critical. The difference between a 3s and 1m loop is huge in my productivity. But if a 1-minute loop meant not fighting issues related to build-tree vs. installed, full graphical session vs. jhbuild session, etc. issues, I'd very gladly take it. And 1 minute is just an arbitrary number. I'm sure we could minimize the lag added by installation, session initiation, etc. > I also realize this is a lot of work, but frankly better > relocatability is > something that benefits our workflow (I would be able to actually > run Evolution Mail in jhbuild without interfering with my mail > account, > I would be able to see what GTK+ apps look like to those select > few who are actually running the bleeding edge of GNOME on a > > device)... i.e. it would not only beneficial for installed tests, but > it would help with installed tests too. Any real solution is going to take a lot of work, which is probably why it hasn't happened yet. But we need something along the lines of OSTree + VM + a simple, standard method to create fast
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
On Tue, Apr 30, 2013 at 12:33 PM, Tristan Van Berkom wrote: > There are two paths I can see which an application can take to be > touch friendly: > > a.) Distribute a completely separate binary designed for touch > > b.) Try to do what gnome-shell seems to be trying, i.e. detect > whether the app is running in a touch environment, and > make specific tweaks, use separate UIs for the touch environment > than the app would use with a mouse driven environment. Well that assumes that touch and pointer a mutually exclusive, which they aren't. Think about "laptops with touchscreen" is it a pointer based device? Or a touch based? It is neither it depends on how the user currently use it. I don't know how to solve this but touch vs. pointer are (no longer) mutually exclusive. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME throbber inconsistencies?
Hi, The GTK+ throbber is a dotted animation, but the one used in clutter apps / UIs use a different icon - instead of dots, it uses longer lines. Is this a design decision? If it is please consider the points made below: - It is inconsistent without an obvious reason as to why this is - The clutter-themed throbber is also used in the Adwaita cursor theme (forked from DMZ-Black(?)), and with the lines which are thicker than the dotted GTK one, it makes the cursor look excessively cluttered (pun not intended), especially in the in progress cursor (I don't know what it is called, but it is the one in between the (O) loader, in Windows it is the Hourglass, and in OSX it is the spinning beach ball, and the normal cursor. It is basically the normal cursor with the circle attatched. It takes up nearly all space in its allocated circle). See the second and third cursors from the following link for case in point: http://codzoyer.deviantart.com/art/Adwaita-Cursors-for-Windows-208885897 In my opinion, I think the throbbers should be consistent on all UIs - if this is to happen, then the GTK one should be used because of the second point outlined above. Again, is this a design desicion? Thanks, - - Marco Scannadinari P.S. Sorry for the HTML email - it was written on a tablet at the time ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.9.1 tarballs due
The development cycle inexorably marches on, and without anybody noticing, the 3.9.1 release is already upon us ! I hadn't noticed this until today, so I'll extend the tarball deadline until tonight, and hope that we can get at least a few releases done. Sorry for the late notice, Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
On 04/30/2013 11:37 AM, Allan Day wrote: > It should also be said that this pattern does have benefits when you > are using a pointer. An obvious example of this is the difference > between single/double click. Not only is double click not exactly > ideal on a touchpad, but it is also used inconsistently and is > non-discoverable (some places you need double click to open, others > you need single.) In general, using single click consistently is a > much better approach, especially when combined with discoverable > mechanisms for selection. FWIW, the one-click/double-click discussion is a really long-discussion. In fact there are a 10 years bug still open about adding the possibility to configure the behaviour. The good news news is that it seems that there are recent activity on that bug [1]. Additionally, there is also a wiki page related with that: https://live.gnome.org/SingleClickPolicyPlan It was started with an accessibility-pov in mind, but as you are saying, there are several other reasons to discuss about that. So just pointing to avoid a disaggregated discussion. About my personal opinion: * As others said, it is needed to have a consistent behaviour on the platform. * If the consistent behaviour includes two-clicks for some situations, it should be configurable, that is what the bug tries to solve. * Probably should be also configurable if a "only one-click" policy is defined (but put more priority on the former). Best regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=121113 -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
> > The selection pattern has been evolving a bit, and we have a round of > design changes planned which we will hopefully happen this cycle. Me > and Jakub literally have a list of things that can be done to the > selection mode to make it better with a pointer. Once we're done I > don't think it will be any worse than the selection mechanisms that we > have in nautilus today. Did you see that we've already brought back rubberband selection ? I hope that fits into your plans. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
I've been holding back from participating in this discussion, because I don't really want to cause unrest, but I feel I should say some things from the POV of someone who has been working with touch interfaces for over a decade. First, I think it's a noble effort to try to provide a desktop environment which is both touch friendly and mouse friendly, but we should really be careful and recognize the challenge it presents. Also, we should make no false illusions that this effort can easily carry through to applications which run in this desktop environment, applications from system settings configuration UIs, text editors to audio/video player applications, all need special care when adapting to touch. There are two paths I can see which an application can take to be touch friendly: a.) Distribute a completely separate binary designed for touch b.) Try to do what gnome-shell seems to be trying, i.e. detect whether the app is running in a touch environment, and make specific tweaks, use separate UIs for the touch environment than the app would use with a mouse driven environment. On Tue, Apr 30, 2013 at 6:37 PM, Allan Day wrote: > Juanjo Marín wrote: > ... >> But also some problems has arisen in the effort of being compatible with >> touch devices.For example, I think that the UI of new applications like >> Documents are very touch friendly, but it's weird for keyboard + mouse >> users. It is weird because the interaction is very different from other core >> applications like Nautilus (Files). In Nautilus, double click opens a file, >> but only one click opens it in Documents, and the way of selecting elements >> and doing actions with selected elements is quite different. I think >> Documents works great in touch screen devices and it is a little bit clumpsy >> with mouse, and Nautilus works great in mouse and keyboard but not so good >> for touchscreen devices. > > Right, so the selection design pattern is probably the most prominent > place where touch compatibility has had an impact. It should be > emphasised that it is somewhat unique in this regard. This comment is why I was prompted to jump in to this conversation actually, I can point out a couple examples where apps in Touch environments should behave differently, asides from single/double click / kinetic scrolling and behaviour of input events. a.) Larger buttons, larger screen area to catch events. This has already been mentioned before, and is probably the least significant issue (applications can provide larger buttons in Touch environments probably easily, without changing the UI functionality much). However, it should not be ignored that Touch requires very large screen areas compared with Mouse driven environments, and in Mouse driven environments you really, really want to economize screen realestate by making some controls small. An example of this would be the toolbar in LibreOffice, this simply cannot be done in a Touch environment realistically without really offering a separate UI for Touch envirnoments. b.) Behaviour of sliders, aka GtkScale This one has been overlooked I think, and is very important to note. On our Touchscreen operated Jukebox system we had custom widgets for GtkScale to deal with the different expectations one would have from a Touch driven environment. The slider had 3 different modes to cope with sliders used in different scenarios: 1.) Browser Mode Browser mode is used when navigating in a list of content, for instance a window full of album jackets with a slider, where the current letter index into the content is printed on the "knob" The specifics of Browser mode is that the "knob"/"position" jumps directly to the click position whenever the "trough" area receives a button press event. In this case, you really dont want the behaviour of GtkScrollBar, which jumps "page size" in a given direction for every click on the "trough" area, instead you want the knob to go directly to letter "M" or whatnot. 2.) Volume Mode When interacting with a volume control "knob" on a slider, I cannot stress enough how paramount the importance is to not have "Browser Mode" functionality in Touch. I.e. when playing with the master volume (or "Bass" control slider even), you never want to risk that the volume jumps to the maximum when touching the "trough" area above the "knob". In this case, what you want to do is let the finger press the "trough" area, and not modify the slider position *until* the finger moves into the "knob" area... once the finger has entered the "knob" area, then you want the knob to start following the finger position until either the finger leaves the slider area completely or there is a "button-release-event". 3.) Strict Mode This is like the above mode I described as "Volume Mode", except that it *never* modif
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Hi Allan, > The selection pattern has been evolving a bit, and we have a round of > design changes planned which we will hopefully happen this cycle. Me > and Jakub literally have a list of things that can be done to the > selection mode to make it better with a pointer. Once we're done I > don't think it will be any worse than the selection mechanisms that we > have in nautilus today. > Would you say that it will be so good that it could (would) be ported to Nautilus too, for consistency's sake? Or is "dealing with file systems" considered as a pointer-only task? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Juanjo Marín wrote: ... > But also some problems has arisen in the effort of being compatible with > touch devices.For example, I think that the UI of new applications like > Documents are very touch friendly, but it's weird for keyboard + mouse users. > It is weird because the interaction is very different from other core > applications like Nautilus (Files). In Nautilus, double click opens a file, > but only one click opens it in Documents, and the way of selecting elements > and doing actions with selected elements is quite different. I think > Documents works great in touch screen devices and it is a little bit clumpsy > with mouse, and Nautilus works great in mouse and keyboard but not so good > for touchscreen devices. Right, so the selection design pattern is probably the most prominent place where touch compatibility has had an impact. It should be emphasised that it is somewhat unique in this regard. The selection pattern has been evolving a bit, and we have a round of design changes planned which we will hopefully happen this cycle. Me and Jakub literally have a list of things that can be done to the selection mode to make it better with a pointer. Once we're done I don't think it will be any worse than the selection mechanisms that we have in nautilus today. It should also be said that this pattern does have benefits when you are using a pointer. An obvious example of this is the difference between single/double click. Not only is double click not exactly ideal on a touchpad, but it is also used inconsistently and is non-discoverable (some places you need double click to open, others you need single.) In general, using single click consistently is a much better approach, especially when combined with discoverable mechanisms for selection. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libRSVG development
I contacted Hiroyuki Ikezoe and Christian Persch three weeks ago asking for the current development status of librsvg (I attached my mail, I hope it doesn't sound unkind?). I didn't receive any answer yet, though... Any ideas what could be done in this case? Regards Eduard Am 02.04.2013 21:04, schrieb Andre Klapper: Many projects are neither extremely active nor completely unmaintained. (In case of librsvg, maintainers did some hacking seven months ago.) It might be worth to contact maintainers explicitly (see https://git.gnome.org/browse/librsvg/tree/librsvg.doap ) and kindly ask for review of specific patches (overview of unreviewed patches at https://bugzilla.gnome.org/browse.cgi?product=librsvg ), or to issue a call for new blood (or invite active patch writers to co-maintainership) if there is no interest in maintainership anymore. --- Begin Message --- Dear Hiroyuki, Dear Christian, I've got a question regarding librsvg development and you're listed as the project's maintainers. Basically I want to know if you're still planning to actively develop the library or if you're only providing basic support. Even If you don't plan to actively develop the library any more I want to ask if you're still willing to apply patches by other authors or if new developers have to be recruited in order to enhance the library further. The reason for my request is a patch I wrote myself and which I had submitted to Bugzilla over four months ago (https://bugzilla.gnome.org/show_bug.cgi?id=605875#c9) but for which I never got a reply. It seems there are also other patches currently waiting for review. Also the GIT repository's log is a little quiet. The last commit that wasn't some kind of build fix but really changed librsvg's functionality seems to be older than a year. Just to be clear: This isn't some sort of criticism. I'm just curious what the current state of the project is and if it makes sense if I put additional effort in creating patches for problems that affect me most in the future. The reason for my personal interest in librsvg development is that I'm quite active on Wikimedia Commons and other Wikimedia projects and Wikimedia's SVG renderer of choice is currently librsvg. Therefore one often has to work around specific renderer bugs (Wikimedia has a list on their own, too: https://bugzilla.wikimedia.org/buglist.cgi?order=Importance&component=SVG%20rendering&product=Wikimedia). I'm looking forward to your answer and would be glad if it is positive. Regards Eduard --- End Message --- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
