Support Back/Forward Mouse Buttons to navigate (gtk2 and gtk3) #605

Closed
wants to merge 1 commit into
from

Projects

None yet

6 participants

@mmatuska mmatuska changed the title from Fixes mate-desktop #78 (gtk3) to Support Back/Forward Mouse Buttons to navigate (gtk3) Aug 8, 2016
@monsta
Member
monsta commented Aug 17, 2016

@raveit65 @XRevan86 @lukefromdc @flexiondotorg

Guys, anyone has the proper mouse to test it? I'm using a simple mouse with two buttons and a wheel... 😄

@lukefromdc
Member

Same here: two buttons and a clickable wheel only

On 8/17/2016 at 4:30 PM, "monsta" notifications@github.com wrote:

@raveit65 @XRevan86 @lukefromdc @flexiondotorg

Guys, anyone has the proper mouse to test it? I'm using a simple
mouse with two buttons and a wheel... 😄

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#605 (comment)-
240537751

@mmatuska
Contributor

It would really be great to have this included in the next patchlevel release

@lukefromdc
Member

Does anyone here have a mouse that can test this? One person was able to write
the patch at least. I am not employed and cannot afford to buy new hardware for
test purposes.

Alternately, is there aany way to emulate this in (other) software or in xorg.conf
or some such way?

On 8/24/2016 at 7:01 PM, "Martin Matuška" notifications@github.com wrote:

It would really be great to have this included in the next
patchlevel release

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#605 (comment)-
242234902

@mr-blobbyyy
mr-blobbyyy commented Aug 27, 2016 edited

I'm glad I found this. Been on mate for a couple months now and the mouse navigable buttons not working on icon hover has been a huge source of frustration. I have a logitech g402 and actually it remembered its own macros from my previous win7 install, which is nice as no logitech software is needed -- so long as you set the macros up in windows first, lol. In my g402, mouse button G8 is hardware-binded to "ctrl+w" which is handy for navigating around in various apps. I'm still relatively new to Linux but I'm willing to clone the current master and recompile entire mate if I have to -- just to fix this very issue.

@monsta
Member
monsta commented Aug 31, 2016

BTW, #78 seems to be about GTK+2, and there's also the detailed status of the issue described by @drws in the comments. Is there any fix for all that?

@mmatuska
Contributor

Yes, this one is for GTK2 (not that simple anymore): mmatuska@1393ecc

@monsta
Member
monsta commented Aug 31, 2016

No pull request for that one?

@mmatuska
Contributor

That one was never accepted by gnome but comes from the same authors. If we can place correct #ifdef's I could unite these two into one larger pull request. What is the best define to find out if I am compiling against gtk2 or gtk3?

@monsta
Member
monsta commented Aug 31, 2016

If it wasn't accepted there, we better give it some additional testing to be sure 😄

For checking GTK+ version at build time, we use GTK_CHECK_VERSION macro:

#if GTK_CHECK_VERSION (3, 0, 0)
// here goes stuff to do in GTK+3 build only
#else
// here goes stuff to do otherwise, i.e. in GTK+2 build only
#endif
@mmatuska mmatuska changed the title from Support Back/Forward Mouse Buttons to navigate (gtk3) to Support Back/Forward Mouse Buttons to navigate (gtk2 and gtk3) Aug 31, 2016
@mmatuska
Contributor

I have updated the patch for both gtk2 and gtk3

@monsta
Member
monsta commented Aug 31, 2016

Thanks. You can actually squash the commits into a single one, and also use checking for 3.0.0 (we're targeting 3.14 as minimum version for GTK+3 build anyway these days).

@mmatuska
Contributor

I have not squashed the commits because the credits go to two different persons. The checking against 3.4.1 is because that is the first gtk3 release that supports the new short version. If you insist it can be changed to 3.0.0 but then it is not exact and may make debugging harder (e.g. looking at the gnome code).

@raveit65
Member

Our minimal support version is 3.14, so 3.4.1 does make any sense.
Why should version check make debbuging harder?
I read currently 3.0.0, 3.16.0, 3.18.0, 3.20.0 and 3.21.0
If we make packages gtk3 only in future, btw. some packages are gtk3 only right now, all checks < 3.14 will gone ;)
Our goal is to simplify code and adding more Version checks doesn't do that.

@mmatuska mmatuska Fixes mate-desktop #78 for gtk2 and gtk3
Co-Authored-By: Oliver Joos <oliver.joos@hispeed.ch>
Co-Authored-By: Nelson Benitez Leon <nbenitezl@gmail.com>
14c6fd0
@mmatuska
Contributor

I have changed the check to 3.0.0, rebased to 1 commit and added two Co-Authored-By: fields according to kernel.org Commit Message Conventions

@mmatuska
Contributor

Has this thread gone dead? Anyone still watching?

@mr-blobbyyy

@mmatuska Hopefully not, I'd like to see this implemented asap. I've raised the issue with Martin Wimpress himself so hopefully he will comment on the Ubuntu podcast (which gets released tomorrow.)

@raveit65
Member

Has this thread gone dead? Anyone still watching?

No, but no one has a 5 button mouse to review/test it at the moment.

@mr-blobbyyy
mr-blobbyyy commented Sep 22, 2016 edited

@raveit65 I can can't review it.

@monsta
Member
monsta commented Sep 25, 2016

@mr-blobbyyy: thanks, would be nice.

@mr-blobbyyy
mr-blobbyyy commented Sep 28, 2016 edited

Just, uh...can anyone give me a few pointers on how to compile this caja branch correctly within mate? I've only done a few git checkouts and make installs before...those have all been on master branches or releases on different projects so I want to be sure I know what a should be doing (versus say, fooling around and breaking things ( ͜。 ͡ʖ ͜。))

edit: I have mmatuska's fork. Just need instructions from here.

@monsta
Member
monsta commented Oct 2, 2016

It should be enough to clone that repo and checkout to gtk3-mouse-forward-backward branch, then build it as usual.

@mr-blobbyyy

@monsta and others, can I do a checkinstall to have a convenient deb in case things blow up? Are things going to work out installing "on top of" the previous install of caja? These are the things I'm thinking about...

@lukefromdc
Member

I've used checkinstall debs for years, but not as checkinstall packs them by
default because
/usr/share/glib-2.0/schemas/gschemas.compiled
/usr/share/icons/hicolor/icon-theme.cache
and worst of all a bunch of folders in /usr/share/mime get copied into the .deb
package. It will install if there is exactly ONE, but removal can (usually won't)
trash your /usr/share/mime directory and kill your desktop.

Here's what works:

1: call the source package something like caja_1.16.0, using the underscore
to create a deliberately invalid name

2: build and run checkinstall, it will error out on a failure to build the package
and hold open waiting for input on seeing the log file. Ignore that for now,
leave it open.

3: Naviagate to /var/tim/(something)/package and copy everything into a directory
somewhere else with the desired name of the .deb but without the .deb extension

4: Open that directory, remove
(packagedir)/usr/share/glib-2.0/schemas/gschemas.compiled
(packagedir)/usr/share/icons/hicolor/icon-theme.cache
and everything in (packagedir)/usr/share/mime except the "packages" directory, which
contains only the item added by this package.

5: change ownership and group to root for the package directory as insurance against
possible installation with user ownership (seen this in the past but not recently)

6: Run dpkg -b (packagedir) and there is your .deb package. This is one deb per source
file, you might want before building to edit DEBIAN/control to "provide" the related
debian packages (*-data, *-dev etc).

This is how I build all my MATE, GTK3, Kdenlive etc debian packages.

On 10/2/2016 at 5:16 PM, "mr-blobbyyy" notifications@github.com wrote:

@monsta and others, can I do a checkinstall to have a
convenient deb in case things blow up? Are things going to work
out installing "on top of" the previous install of caja? These are
the things I'm thinking about...

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#605 (comment)-
250996616

@mr-blobbyyy
mr-blobbyyy commented Oct 3, 2016 edited

Someone else might need to take over reviewing duties as I'm afraid I'm not knowledgeable enough in the dependency department: No package 'mate-desktop-2.0' found 😢 🔫

@lukefromdc
Member

If a package is not found at build time, some of the development files (I think the .pc files) are not installed. In Debian and Ubuntu, these are the -dev files from the set perhaps best described this way. Source "mypackage" builds to a set of Debian packages that may include "mypackage" mypackage-common" "mypackage-data" "mypackage-dbg" and the one you need "mypackage-dev" .

If you install the dependencies (or all of MATE) from source these files will already be present.

@mr-blobbyyy

Ok, after doing some digging I managed to come up with a (non comprehensive) list of dependencies for ubuntu/mint:

checkinstall
libglib2.0-dev
gobject-introspection
libmate-desktop-dev
libcaja-extension-dev
libxml++2.6-dev
libgail-3-dev
libgtk-3-dev

However, libmate-desktop-dev is still an issue because autogen still wants a version >= 1.15.1. Mint is on 1.14.1 (and ubuntu is still on 1.12.1, lol.) Is it worth trying to install the newest version of mate-desktop considering the Mint-specific mods to mate?

@raveit65
Member
raveit65 commented Oct 3, 2016

This does not make any sense :)
@mr-blobbyyy What version have your installed caja package?
@monsta @lukefromdc Can you please build a deb and upload it somewhere?

@mr-blobbyyy
mr-blobbyyy commented Oct 3, 2016 edited

edit: my installed version is the default on in LM18 -- Caja 1.14.2 (1.14.2-1+sarah).

@monsta
Member
monsta commented Oct 3, 2016

I'd not mix 1.16 and 1.14 packages just in case. Yes, you can build 1.16 versions of mate-common, mate-desktop and eventually caja, and install them, but we can't guarantee it will work in 1.14 environment. Maybe yes, maybe no, maybe rain, maybe snow... 😄

@mr-blobbyyy
mr-blobbyyy commented Oct 3, 2016 edited

Well, in that case, we need to crowdfund a $37 mouse and send it to @monsta. Give me a Dogecoin address, I'll put in $5 💵 😂

@mmatuska
Contributor
mmatuska commented Oct 3, 2016

You guys are really surprising. What about installing Arch Linux or at least Ubuntu 16.10 in a VirtualBox? You can pass USB devices to VirtualBox.

And just for this you can find a 5-button mouse for $10-$15.

@flexiondotorg
Member

The Ubuntu MATE crowd funding has sent some money to @raveit65 so he can test this pull request using a 5 button mouse :-)

@mr-blobbyyy

Thanks Martin, glad you can make this happen. Here's a small reviewer's guide for @raveit65:

  1. First, confirm back and forward on the mouse are working out-of-box. In firefox or other browsers, the back and forward webpage function should work natively.
  2. Confirm the limited back and forward function already existing in Caja -- clicking back/forward when the mouse cursor is over empty space for both "icon/compact view". (This also includes empty space between icons in both "use compact layout" and also unselected. Technically, the empty space within Caja's window is called "input box" -- you can modify the color specifically if you want in the appearance settings.)
  3. Now try for the implemented fixes: clicking back/forward while directly hovered over an icon in "icon/list/compact view". In "list view", note if the icon gets unexpectedly "selected" while hovered when clicking back/forward (this is the current behavior.) Make sure it works also when hovered over empty space in "list view" as well.
  4. Make sure behavior is expected: "single press in to execute" versus "single press in and out to execute" and also make sure icons are highlighted when hovered.
  5. Look for bugs while clicking back/forward all over the window. This includes the title bar, most of the window elements outside of the input box, the "places" sidebar, over the "resize" sidebar, scroll boxes, and also within right-click context menus (current behavior is "select item" while in a context menu.) Also check on the resize window borders as well.
@raveit65 raveit65 referenced this pull request Oct 12, 2016
@lukefromdc lukefromdc GTK3: port libunique ->GtkApplication as build time option
Add --disable-libunique configuration option for GTK3 builds. This builds a port from libunique to GtkApplication. keep GTK2 builds unchanged

Caja can now be build with GTK2 and libunique, GTK3 and libunique, or GTK3 without libunique using GtkApplication instead

GtkApplication port  Based on cherrypicked nautilus commits from
GNOME/nautilus@a8481ee
main: adapt to GtkApplication changes
through
GNOME/nautilus@c3382e0
application: move nautilus_application_new() to its own function

GTK3/GtkApplication builds:  add --force-desktop option
This is useful for other DE's

All: StartupNotify=false in .desktop files, as caja never connects to notification daemons and in GtkApplication builds this causes busy spinning curors
9e5ea15
@raveit65
Member

Weird, with latest caja from master (gtk3) back/forward buttons are working out of box in iconview/compactview and if the mouse is over other elements like menubar, statusbar, primary-toolbar and sidebar.
Only if the mouse is over listview clicking button4/5 does have any effect.
So what does the PR fix?

@mr-blobbyyy
mr-blobbyyy commented Oct 14, 2016 edited

So what does the PR fix?

Like I said previously, my understanding is the PR would fix functioning if the cursor is hovered specifically on any icon in all 3 views (versus just empty space.) If you're saying this works on the master that would be...interesting.

Only if the mouse is over listview clicking button4/5 does have any effect.

I'm sorry, I don't understand this. Are you saying it does "not" function in list view?

When you mentioned "menu bar" I did some more testing on my version (1.14.2) and found something interesting. In this very confined area (and no where else in the window), back and forward does indeed function on: "single press in and out and in" -- almost like double-clicking -- with an added delay not executing on the 2nd press in. The strange behavior exists in all 3 views. Here's a screenie showing the exact area (enclosed in red) where this behavior exists: http://imgur.com/s0OuW7y

@raveit65
Member

Are you saying it does "not" function in list view?

Yes, It works everywhere except in listview.

When you mentioned "menu bar" I did some more testing on my version (1.14.2) and found something interesting. In this very confined area (and no where else in the window), back and forward does indeed function on: "single press in and out and in" -- almost like double-clicking -- with an added delay not executing on the 2nd press in.

I don't see a delay here. If the mouse is over a menuitem the 4/5 buttons open/close the menu.
Also, it works here if one dir is in 'listview'.

Ok, i will test it with the PR to see if there is a different.

@raveit65
Member

For some reason it works also in gtk2 Mate environment (1.16) w/o the PR, but here only if the mouse is over iconview and compactview, and not in listview.
Looks like i bought a magic mice (SPEEDLINK AXON Mouse) :)
With the PR the forward/back buttons are working also in listview.
Ok, as i see an improvement and it is reviewed by @monsta i will merge it.
I think we can cherry-pick it to 1.16 branch after a while more testing, as it is a bug fix.

@raveit65
Member

A bit rebased and merged 625a06c
Thank you

@raveit65 raveit65 closed this Oct 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment