Description of problem: In #1214057, you set yumex-dnf to remember search options (thanks!), but now the checkboxes for "Fields" need to be unlocked on startup if "Fields" is the saved option. Version-Release number of selected component (if applicable): 4.1.1
thanks for reporting, I will look into this
can not reproduce this if I select 'Fields' and restart yumex-dnf, then the checkboxes is active could you please paste your cat ~/.config/yumex-dnf/yumex.conf
Happens when only change from default is selecting "Fields" ... [yumex] autocheck_updates = 0 autostart = 0 update_interval = 60 update_notify = 1 update_showicon = 1 update_startup_delay = 30 system_refresh = 2015-04-29 11:37 search_default = key win_height = 692 win_width = 1016 Tested on Fedora 21.
Strange, I can't reproduce it. I have tried using your yumex.conf, I just work for me (I'm using F22) Do you see the issue when starting yumex-dnf, with default=fields or when starting with default=key and selecting 'fields' from the menu ?
Actually, we just uncovered another bug which is probably related ... I didn't notice that search_default got switched to "key" -- it was set to "fields" ... Here are my reproduction steps for this second issue ... 1) Start yumex-dnf, switch the search option to "Fields" 2) Close yumex-dnf If you open ~/.config/yumex-dnf/yumex.conf at this point it will show search_default with the "fields" value. 3) Start yumex-dnf, click the search options dropdown to see which is selected ... "Fields" is selected, but the checkboxes are unclickable. 4) Close yumex-dnf If you open ~/.config/yumex-dnf/yumex.conf at this point it will show search_default with the "key" value. (This happens the second time you close yumex-dnf after switching to "Fields", regardless of whether you interact again with the search options dropdown.) 5) Start yumex-dnf, click the search options dropdown ... "Key" is selected. To answer your first question, yes, I see this issue when starting with search_default set to "fields". To answer your second question, no, there is no problem interacting with the checkboxes immediately after switching through the dropdown from key (or prefix) to fields ... the problem is only after closing yum-dnf and then opening again.
I'm wondering whether this second bug is causing the first or if the first bug is causing the second? I'd test in F22, but it's not very practical for me since they don't release a Mate spin of the beta....
Actually, they do, though it's not linked anywhere from the site that I can see. But I've got another 7 hours of downloading something else before I can get to that. I don't have the world's fastest Internet connection :-P
Still can reproduce it :-( 1. start yumex-dnf 2. select 'fields' 3. close yumex-dnf 4. cat ~/.config/yumex-dnf/yumex.conf | grep search_default search_default = fields 5. start yumex-dnf 6. fields is selected and field values is active (see attachment) 7. close yumex 8. cat ~/.config/yumex-dnf/yumex.conf | grep search_default search_default = fields
Created attachment 1020427 [details] screenshoot of yumex-dnf (fields is default)
Can you check if you can reproduce using an upstream checkout git clone https://github.com/timlau/yumex-dnf.git cd yumex-dnf make get-builddeps make test-inst
(In reply to John from comment #6) > I'd test in F22, but it's not very practical for me since they don't release > a Mate spin of the beta.... https://spins.fedoraproject.org/en/prerelease
Tested with a fresh install of F22 beta with same result. Will get back to you with more test results. @Wolfgang -- thanks ... I did finally find that. (I think I forgot to take my smart pills yesterday!)
Same problem with upstream checkout.
This was previously tested with *fresh* installs of F21 and F22 beta. I have now tested with a fully updated install of F21 and the problem no longer manifests. Presumably the issue was addressed by an update to a package which yumex-dnf depends upon. Another possibility might be that there's a glitch which occurs only when there are any/many updates listed in the GUI.
(In reply to John from comment #14) > This was previously tested with *fresh* installs of F21 and F22 beta. I have > now tested with a fully updated install of F21 and the problem no longer > manifests. > I run a fully updated F22, so comply with my testing that I can't reproduce the issue. It could be som issue in GTK
Made some tests on a fresh F22 xfce system. 1. On a clean system, I could reproduce the issue. 2. installed all updates excl. gtk3, the issue is still there 3. updated gtk3 3.16.0-1 to 3.16.2-2, and the problem disappeared.
Test on F21 and downgraded gtk3 $ dnf downgrade gtk3 gtk3-immodule-xim Then the issue is there again So the issue is clearly related to some issue fixed in a recent gtk3 update.