[Touch-packages] [Bug 1164016] Re: restore type-ahead find
I think a nice way to solve this stupid debate could be to ensure that the files are displayed in a STABLE order - type ahead results from the current folder first - folders first - files in the current folder before the other files... what is MOST annoying with the current feature is that when you have spotted the file you're interested it (or quite often the folder) then - there can be other files/folder with the same name and it is impossible to know which is relevant (it should be the closest, the one from the current folder, etc). It seems to be the last used, so it changes - when you have spotted the folder or file you want to open, the time you move your pointer to open it the files are reorganized as further search has been done, and you open some other random file. How is it possible to maintain such a feature the way it currently works? The search should be done in some order, and this order should not change so rapidly while you're trying to find your result... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/1164016 Title: restore type-ahead find Status in Nautilus: Expired Status in nautilus package in Ubuntu: Fix Released Status in ubuntu-settings package in Ubuntu: Fix Released Bug description: GNOME removed type-ahead find in Nautilus 3.6, not without controversy: https://mail.gnome.org/archives/nautilus- list/2012-August/msg2.html Now when you type in a Nautilus window, Nautilus immediately performs a search in the current directory and all its subdirectories. I personally find this annoying. If I want to search, I'll click the search icon. Often I'm looking at a long directory listing and simply want to jump to a certain point in it, and type-ahead find works great for that. Would Ubuntu consider patching type-ahead find back in? To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1164016/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1574347] Re: [SRU] Re-read the link type if the name changed
Ubuntu 16.04 on dell E6430, after upgrade: - after suspend/resume sometimes the network manager cannot connect (but it tries: it keeps associating/de-associating) [before upgrade, the wifi was broken at this stage, cf below] dmesg: [101381.710749] wlan0: authenticate with 42:01:40:59:9f:3c [101381.712600] wlan0: send auth to 42:01:40:59:9f:3c (try 1/3) [101381.714512] wlan0: authenticated [101381.716173] wlan0: associate with 42:01:40:59:9f:3c (try 1/3) [101381.726242] wlan0: RX AssocResp from 42:01:40:59:9f:3c (capab=0x411 status=0 aid=4) [101381.728513] wlan0: associated [101388.076989] wlan0: deauthenticated from 42:01:40:59:9f:3c (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) [101388.104508] cfg80211: World regulatory domain updated: [101388.104511] cfg80211: DFS Master region: unset [101388.104512] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) - if I deactivate and then reactivate the wifi, then it reverts to the old bug (where there is only one network available and nothing happens). sudo service network-manager restart repairs everything... The bug is still at this point: [101418.822530] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [101418.869145] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [101423.443499] e1000e: eth0 NIC Link is Down [101426.202627] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [101426.202873] iwlwifi :03:00.0: L1 Enabled - LTR Disabled [101426.210391] iwlwifi :03:00.0: L1 Enabled - LTR Disabled [101426.210491] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 [101426.434605] iwlwifi :03:00.0: L1 Enabled - LTR Disabled [101426.442165] iwlwifi :03:00.0: L1 Enabled - LTR Disabled [101426.442267] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 a problem with the /dev/something, no? strange... hope this can be repaired soon. But also in the 14.04 distrib it was sometimes necessary to deactivate/restart the network manager to catch back the signal after resume... good luck, thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1574347 Title: [SRU] Re-read the link type if the name changed Status in NetworkManager: Fix Released Status in OEM Priority Project: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Released Bug description: [Impact] NM needs to re-read the DEVTYPE after the device name changed, an example is that WiFi network list disappears from network manager applet [Testcase] 1. Boot the system. It should include a wireless device. 2. In a terminal, run 'nmcli dev'. 3. In the correct case, the line for the wireless device should read "wifi" under the TYPE column. In a failure case, it will read "ethernet". After upgrading to the new version, the repeating the above steps should give expected behavior. [Regression Potential] Potential of causing regression is relatively small for a one line change to re-read a value to be known. --- Problems:- 1. The network manager applet does not show the list of WiFI APs it can find. 2. The network manager applet does not the name of the AP to which it is connected 3. The icon of the applet shows two vertical arrows in opposite direction - the wired connection symbol and NOT the wifi connected icon. Temporary Workaround:- Log out and again log back in. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1574347/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 674138] Re: "Global" appmenu breaks sloppy focus
Dave Gilbert : Indy is right the f-f-m option sets the focus on the last window visited, and as long as windows are open the desktop never gets the focus. It means it is impossible to rename an icon on the desktop (or you need to open a file browser and open the desktop inside the file browser) What I don't understand is that this issue would be solved with a very simple variant of focus-follows-mouse : the behavior should be that 1- it focuses on the window under the mouse 2- it keeps the focus on the last window visited when the pointer is on the desktop 3- it focuses on the desktop if you click on it (and in general on any window you click in, since sometimes some bug makes the focus loose the mouse). In particular, when you click on an icon in the background (or create it) the focus should be automatically transferred to that icon... currently the behavior is 1+2, but not 3. to sum up, "focus follow mouse" should be a layer onto "click to focus", not an exclusive option. this would still allow to visit the upper bar (for the crazy users who disable the menu-in-window feature). The truth is that f-f-m is so handy that once one has tried it, it is hard to change back. (I first tried it on X-10... hmm, in '91?) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/674138 Title: "Global" appmenu breaks sloppy focus Status in Unity: Won't Fix Status in “unity” package in Ubuntu: Won't Fix Bug description: An option I heavily use in GNOME 2.x is so called "sloppy focus" or "focus follows mouse" (ffm). This feature allows me to have multiple windows overlapping and easily switch between them by 'nudging' the mouse over the window I wish to type in. I do not bring the window to the front. Example scenarios * Whilst watching a TV programme in a large window, I wish to microblog about the TV programme to my followers without distracting myself from the programme. I can hover the mouse over twitter client dialog box without it obscuring the video window. * I am working on a document and need input from a co-worker so I get them on IM. As they explain in the IM window I can be typing in the document window. When I need to acknowledge receipt of the IM I can easily switch to the IM window without losing sight of my document. As I understand it, with global appmenu enabled the menu for a window is placed at the top of the screen and changes as the window focus changes. If I am using focus follows mouse and wish to select a menu item for Window A, then as the mouse moves over Window B en-route to the menu, the menu content will change, making it challenging to select menu options for WIndow A. Under certain circumstances it may be possible to take a circuitous route to get the mouse to the appmenu so the menu content doesn't change, but this is suboptimal. I would like to file a bug to petition for the inclusion of a system whereby:- * Focus follows mouse feature is included in Unity * A system which caters for users of focus follows mouse, and suppresses the sub-optimal behaviour. My personal suggestion is as follows:- * By default Unity be setup with ffm disabled, to use the traditional behaviour as default in current GNOME 2 * An option made available to enable ffm * An option made available to configure a key which can suppress the menu change * Behaviour adopted in Unity whereby when the modifier key is pressed, the user can throw the mouse to the menu and know that the menu will be frozen (i.e. focus changes will be ignored) until the modifier key is released. Whilst I appreciate that the vast majority of users do not use sloppy focus, or indeed many don't even know it exists, for those of us that do, it's an integral way in which the desktop is used. To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/674138/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
