20.04 daily testing: Qterminal windows too tall?

I was just trying to increase Qterminal’s scroll buffer so I can capture all of Calamares debug output. I go to preferences->behavior, and the bottom of that window extends below the bottom of the screen. There’s no way to press whatever “ok” button is down there. There is a fairly large amount of whitespace in the middle of that screen (beneath $TERM).

To revive a different topic, I don’t understand some of the defaults Lubuntu uses. 4 workplaces (and heavy screensavers – when screens don’t need saving nowadays). But, a cautious 1000 lines in the terminal.

Anyway, if the “behavior” page’s enormity should be reported as a bug, let me know and I will. (I know I can redirect output to a file. I’m never clear with Live systems where that’s going, or what’s writable. I just wanted to copy/paste it. I think I can enable autohide for the taskbar, and see the “ok” button.).

4 workspaces takes minimal if any extra RAM (I think it’s the same RAM if 1 or 4, or …) the only ram used is the need for Desktop.Switcher (desktopswitch) in the panel (which is small)

Screensaver is used for locking screens; so whilst not all users want the fancy ‘dizzy’ and other xscreensaver-gl (https://packages.ubuntu.com/focal/lubuntu-desktop) savers, about half the users do, and beyond some power/heat during operation the largest impact is to ISO size in my opinion.

The buffer backwards however does use RAM, if terminals were 80 (but no-one uses 80 anymore) characters wide; 1000x80 plus overhead (per terminal/tab open; and even if not predefined array of set size, there is overhead when garbage collection will be needed to string space). One benefit of the 1000 is that’s set upstream, so Lubuntu is just using defaults, as changing defaults requires a packager to have more work, so defaults are commonly kept unless there is a good reason.

I’ll have a look at Qterminal on a ‘live’ system with 1024x768 display (I think my smallest display size) when I can. I know that’s been talked about/addressed before, but some time ago.

I just opened a Qterm, changed the lines to 100,000, and executed the free command about a 500 times. I didn’t see any significant difference in memory usage. I have 9gig free. It’s not eating into that at all. I assume it’s going straight to disk as a buffer in a tmp file?

Also, I’ve never said the four virtual desktops use more memory. I’ve always said it strikes me as a perception issue (more beckoning of usage than other, non-lightweight distros). That always stands out to me when I see other things that seem unusually lightweight. You can disagree with that opinion. But, I’ve clarified this more than once. I shouldn’t have to keep saying “that’s not what I said.”

Are the number of virtual desktops configurable? I’m not seeing that anywhere.

I was just running qterm with 1000 & 10000 lines, watching it with Htop. I didn’t see any difference beyond the normal up and down memory usage. (I stacked “ls -la; ls -la” a dozen times on the command line. Then, up-arrow/enter over and over until the buffer was exceeded.). I didn’t see any significant difference one way or the other (compared to opening menu->preferences->lxqt settings->lxqt config ctr.).

I booted yesterday’s 20.04 daily on d755-8 (with two old dell 1280x1024 & 1024x768 displays), and yes on 1280x1024 I did have qterminal preferences OK/Cancel/Apply button obscured by the bottom panel, that issue has been addressed before, and I could work around it easy enough (eg. made panel autohide). I didn’t have any issue on 1024x768 display though.

To change the number of virtual desktops in Lubuntu, go to OpenBox Settings (window will be titled Window Manager Preferences when opened). In our manual it’s found at

https://manual.lubuntu.me/stable/3/3.2/3.2.11/openbox_settings.html

ps: my comments about memory were more theory. The question about virtual workspaces/desktops comes up very often with suggestions to reduce number to ‘save’ ram, alas it doesn’t. On my old 1gb RAM thinkpads I still reduce workspaces even if only to remind me of my restricted ram. With the qterminal I’ve never looked at the code, but my array size was my thinking of how I’d define it and consequences of various approaches if I had to write it.

Yes, it was a lower-resolution. What stood out to me was a fair amount of whitespace beneath the $XTERM line. If that space wasn’t there, it would fit on even lower resolution screens. There doesn’t seem to be any point for that whitespace. I’m on a 1080 screen right now. The page fits on the screen easily. But, that whitespace still begs the question (why is taking up that much space? It’s still covering my workplace more than it needs to.).

I grabbed the source, went into ~/qterminal-0.14.1/src/forms/propertiesdialog.ui and didn’t see anything creating that space. This is my main box with 2x 1920x1080 displays and whilst I don’t know for sure, I get the feeling the size of the window is created by the first Appearance tab which has the most fields (not being table related). The white-space under Default $TERM is just a consequence of that tab containing fewer fields than the window can display; ie. if more settings were added to the screen we’d have less white space. To me the white space is just how the window is created in properties.cpp, and creating extra work to try and alter appearance/behavior would be (a) wastful (I’d never get employed by system76/apple!) or (b) annoying (eg. if window reduced in size because behavior has fewer items than the appearance tab I suspect sets window size)

That makes sense. Sorry, I didn’t mean to make you go to that trouble.

Something seems problematic about it though. How would other desktops handle that? Would they detect that a window is too large for the screen, and add scroll bars? (Is that a function of the desktop or window manager to handle how windows fit? Or, entirely each app’s responsibility to navigate the display size?).

The next time I install Lubuntu, I’d like to play with scaling or accessibility controls and see how that works. I’ve got a feeling it won’t adjust in a good way.).

No trouble as an apt source qterm.. and I’ve got source, a cd followed by fgrep to find detail, then another fgrep to get fewer results (ie. exclude translations) and I’m there… It’s easy with open-source software.

This is opinion, but I’d believe this approach would be the same for KDE that also uses Qt (why the cpp and not c/vala which is more common with GTK). Desktops that use GTK will instead call GTK & thus do whatever it does (ie. GNOME, MATE, XFCE, Budgie…) as why re-invent the wheel and create more work for yourself. You use whatever is provided by the toolkit/stack in use via API call.

(If you want to compare LXDE which used GTK2 (not GTK3), you’d need to comparing it’s appearance/behavior more to an old GNOME2 desktop of long ago, Ubuntu 10.10 or before)

A benefit of using standard API calls, is the window dressing will be standard, and all apps have similar appearance (a nicer experience for users who care about looks).

You can also access the debug info in the calamares session log found at
~/.cache/calamares/session.log after running sudo -E calamares -d .A bit easier than trying to manually copy the terminals output.

2 Likes

Thanks. I noticed you’ve done a lot of testing. You haven’t encountered this experience at all?

I’ve been experiencing it once every day or three. I just had it twice in a row two days ago; and then first thing the following morning. All different machines. That’s why it seemed like a good idea to have logging enabled by default. It’s not the kind of problem where you can rerun it and capture the info. (But, if I’m the only one experiencing it, I understand why it would be ho-hum to others.). I just don’t understand how I’ve experienced it so much, and nobody else has. There is nothing specific to me, or one machine.).

Yesterday, I enabled logging and the problem went away. I cancelled out (as it was formatting, or beginning to “fill disks.”). Ran it again without debug logging, and it failed again. (I ran it again with debug, and it worked.). So, I’m thinking if informative logging were turned on by default, the behavior would probably never be seen. :slight_smile: [I’m not sure why it hasn’t been enabled anyway. The same rationale that this bug isn’t bad would apply to that logging too. People will only experience it once during install. They only install once. Ergo, informative logging shouldn’t be worse than the errors it would bring to light more easily]. Anyway, I’m now thinking Calamares isn’t waiting long enough to see a result. Maybe logging slows it down just enough that it catches what it needs to see. But, that still begs the question: why am I the only one seeing it?

I think I’ve carried this topic as far as I can. I didn’t intend to get this involved in any distro’s testing. I just wanted to make sure 20.04 (generally) works with the newer Ryzen hardware. I landed here because I used Lubuntu for 4 years prior to LXQt. It’s familiar (in both good and bad ways.). I shouldn’t get too involved. My thoughts are not orthodox.

I’m thankful for learning so much about how to contribute testing within Ubuntu’s corporate environment. I will definitely participate with future 20.10.

The strongest conclusion I’ve formed: Ubuntu (corporately) creates it’s own pain points by having unnecessary feast/famine cycles. If every flavor had it’s own release date, there could be more dedicated effort to each flavor. For example, I’m testing each flavor each day (almost). That has prevented me from spending more time trying different things with with any single flavor. It must be the same way with everyone. The old saying, “you can’t squeeze blood from a turnip.” Everyone has their limits.

These feast/famine cycles (along with drop-dead dates) don’t seem healthy to me. It doesn’t maximize resources. It feels toxic, actually. People learn to make excuses for buggy releases because… what’s the alternative? Wait another half year? Beat one’s self to death just to make an arbitrary date? (along with six other flavors all marching to the same arbitrary date?).

Then there are complaints about a lack of volunteers. Why would anyone intentionally walk into a spinning propeller like this? If there’s a problem with not enough people, the first obvious solution is to stagger the release dates so there can be more dedicated (migrant) help for each flavor. Not marathon exercises twice a year. If the problem is self-inflicted (as it appears to be from my perspective), why would people be eager to enable that? (bringing their personal passion to something that is fundamentally setup to exhaust resources & passions; encourage people aim low and make excuses just because they’re powerless to control resources and dates?)

That’s just my takeaway from this experience. I understand there are more “on board” ways of viewing this. I appreciate the availability of Ubuntu distros. I will definitely contribute testing again (and will continue to test until April 20).

Sorry but are you referring to the terminal window size or something else. I seem to have lost the thread. :confused:

I worked for years for a software firm (accounting software) and we were constantly testing,improving and releasing updates.It is part of the business and culture of IT. How many updates does an Android mobile get in a month?
I think you are doing a good job testing and would be great if you could continue and help make the product better!
Cheers,

3 Likes

I’m ignoring all the other stuff unrelated to the main topic and I’d suggest everyone else do the same— until they become their own topics.

Regarding the main topic, this has been addressed upstream and actually fixed in Qterminal. However, there has been no released version since then, so we have no fix. We can try to pull in the patches but that can be problematic. We’ll have to look into it. Not sure we can get this into 20.04 this late in the game.