The control keys at the bottom of the window are hidden off-screen. The application does not allow decrease re-sizing except Minimise.
Exhibited by:
Fedora 31, Cinnamon
Upgrade to 33 and latest Cinnamon.
(knowing Alt+A allows use. Command-line dnf working happily)
What’s your screen size?
Display says “1366x768 (16:9) Recommended”
So, not talking about a smart-phone display or some-such mini-sized screen!
There seems to be no way to adjust the dnfdragora window, nor its internal panels. Thus question seems slightly irrelevant, in that if it won’t allow me, the software should adapt!
Looks like there’s an upstream report about this here: Dnfdragora 2.1.0 window height · Issue #164 · manatools/dnfdragora · GitHub
2 Likes
I recently installed the Xfce spin of Fedora 36 on a machine with 1366x768 screen resolution and I ran into this problem (again). Everytime I bring up dnfdragora on these low-resolution screens I forget that the Apply and Select All buttons are hidden off screen and it is pretty confusing how to proceed when those buttons are not visible.
Anyway, under Xfce, I just Alt-LeftClicked on the dnfdragora window so I could slide the window up and see the hidden buttons. I also responded to the GitHub issue that @mattdm mentioned. Maybe this can get fixed. 
2 Likes
As a follow-up, running dnfdragora with the Qt toolkit doesn’t have the window height problem–it works much better. To use the Qt toolkit, all that I needed to do was:
sudo dnf install libyui-qt
and then I was able to run dnfdragora --qt . The full window is visible on the small screen, giving you access the essential buttons at the bottom of the window.
Another workaround mentioned in response to my comment on the GitHub bug report above was they were able to increase the scale in the Xfce display settings to temporarily make the screen resolution larger. I tried that and it does work with the Gtk version of dnfdragora, though, I think using the Qt version is nicer for now.
2 Likes
Sorry for resurecting an older thread. I recently upgraded Fedora v36 with the Cinnamon spin and found that dnfdragora had the same above problem of not being able to fully adjust the window for screen size. Paul Graham’s solution works just fine for dnfdragora. However, I like to use dnfdragora-updater and I find that the --qt option doesn’t work with it. A search for “dnfdragora-updater command line options” or “dnfdragora-updater man page” provides nothing.
A lot has changed in Fedora since this topic was posted. Please create a new one with your issue, instead.
Whilst it is true to say that Fedora v36 has moved-on since v32, that 2022 is a different world to that of Jan2021/Sep2020, dnf and its updater are still joined-at-the-hip, and the Bug Report has not been marked as solved!
Given that they sound like the same problem, in the same software-set, the request to start a new thread has the effect of diluting this, and dispersing any ‘result’. As the OP, I was not at all unhappy to see the contribution! New/continued topic Thanks to @Paul and @william8000 for keeping the topic alive.
If some capable-person was able to report the problem as solved in dnfdragora vN or libyui vM, or ‘whatever’, and that the corrected-software is included in Fedora vX, that would be a complete-answer.
The side-effect implication (possibly unintended) is that one should upgrade to Fedora 36 is not helpful. Both @Paul and @william8000 report using same and the bug-report (above) has not been closed. Thus, going to the effort of upgrading Fedora to see if such problems persist, in vain/only to find no reward, will generate disappointment/lack of return on investment if you will. Disappointment drives people to consider other distros!
After the discussion of deprecating yum (and its eco-system of GUI and other accessories) in favor of dnf, some years back, I’d have expected the dnf-people to have been keen to find (and implement) a solution - certainly in less than four Fedora versions and all this real-time.
Admittedly, I’ve been doing all such work through the command-line for so long, it’s as if I’ve forgotten that the GUI version even exists…
NB although I don’t recall @Paul’s contribution (apologies!) a quick foray reveals that the libyui-qt is installed (I know not when/why), and that dnfdragora’s buttons are now visible on my system.
Does dnfdragora now display properly on a vanilla-install of Fedora 36? Can I mark this thread as “solved”?
Me too … but thinking of people who are using accessibility options/tools and depend a bit of a working old-school Gui option, it is really unfavorable if this not works as it should.
Not really … I had still to use dnfdragora --qt as @psgnm proposed.
But I guess this is not so a big problem anymore, if someone needs this urgently and with frequentcy, he can ad an alias dnfdragora=dnfdragora --qt to ~/.bashrc .
I think it is ok, If someone reads this he still can following the new topic:
1 Like
I have the same problem on a freshly installed Fedora 36 Mate/Compiz spin (live x86_64 36-1.5) system on a laptop with max screen resolution of 1366x768. dnfdragora 2.1.2 window minimum dimensions exceed the height of my laptop’s screen. This serves to cut off the portion of the window that contains “Apply” and “Quit.” I’m wondering if maybe a “preference” option to relocate these to the top of the window can be provided? Please forgive me, I realize the number of computers with 1366x768 res. screens is not on the up-swing.
Welcome to ask.fedora @tstetler
You need at least ~x860 pix in high to see the controls or using the -- qt option (see above). The software was made when the displays have been more square then today.
Have you tried do work with dnf in terminal?
2 Likes
Whilst, @ilikelinux and myself to ‘solve’ the problem by using a command-line option, such may not suit everyone.
In fact, if the conversation goes like:
0 we have rpm and yum which work happily and have a number of tools built around them,
1 nevertheless, we will now all start to use this swish ‘new’ tool,
2 but it doesn’t work,
3 use something else;
one has to ask the question: if the new tool was so good as to be accepted into Fedora as THE tool for the job, why? and why hasn’t a reported-fault been fixed. Does it sound like ‘flash in the pan’?
Extending point-3, and on the voiced-solution/my experience: isn’t this something like victim-blaming? ie if you have a problem, you must be responsible, aka the authors are each saying: not my fault. Is the conclusion that everyone should go out and replace perfectly-acceptable hardware, just to be able to use this software, that’s apparent advantage is to be more “dandified” than what was working happily for us before?
Given the range of GUI frameworks and tool-kits available, should software ‘just work’ on any size/shape of screen or window, adding scroll-bars when and where necessary, and such-like?
Should shame be directed/pointed/implied for people noting the problem and/or posting here, or does it belong on other shoulders?
Regards =dn
I would add that while dnfdragora may work for some it is not AFAIK installed by default on fedora workstation. As such it is up to the user to install it should they wish to test or use it, and if it does not satisfy them then they really should choose to not use it since there are other tools to achieve the same goals.
The screen size seems to be an issue to refer to the developer, but if the user cannot use it then it is up to the user to find an alternative (of which there are several) The developer may choose to change the default screen size or not, but feedback helps them to choose what to do.
Ranting here achieves nothing productive, feedback to the developers is a more responsible path.
@ilikelinux has given a very good description of the requirements for use, and if your screen does not have adequate pixel height then that app appears unusable on your system.
1 Like
I do agree with you, but I guess it is not your Job to complain for others. I answered to @tstetler, if he reads the whole topic, he knows what possibilities he has.
I flagged your answer, because I guess you misunderstood what opensource means and what kind of work we do here for fedora.
While checking here Team | MATE it is visible that Clement Lefebvre was the founder of Mate and he still is very active with Linux Mint.
If someone is unhappy how the mate spin is mainlined by fedora, this one has the freedom to support the Mate desktop while using Linux mint. There the Mint team is maintaining a fabulous Mate Desktop with a great installer. It is really User friendly for Linux newcomers and such users who insist of a polished and perfect integration between installer and Gui.
I don’t know what is meant with “swish ‘new’ tool”, if it is dnf or what? Everyone is free to use what he wants, this means that probably the Mate spin from Fedora is not the optimal solution and it is time to see if a more user-friendly Distribution satisfies the necessity of the user.
It works, just reading the topic and doing the optimization of using a other resolution or the – qt option.
Opensource software has the advantage that we can:
- Read the code
- Change the code
- And even redistribute it, respecting the opensource license.
If someone can’t, the possibility exists to hire someone who can, and pay it for the work. As the most of us also work for free, things not change the way we always want. Be patient, get active an lower expectations.
Thank you much for the response- just a quick update on my situation. The work-around provided above was successful. I was able to verify both the -gtk and -qt libraries were present on my system, and I removed libyui-gtk. Dnfdragora is playing nice with the remaining libyui-qt. Thanks again.
There is an even simpler workaround: set the environment variable
YUI_PREFERED_BACKEND=“qt”
in your .bash_profile or .bashrc
Dnfdragora then uses the libyui-qt lib and everything works as before.