Better height preference UI

[dbuch]

What about a fullscreen option in the extension settings?

[zzrough]

I do not get why this would require a setting? Usually, fullscreen is tied to F11 and simply makes the window fullscreen. Or do you mean you'd like a setting for the window to use all the screen height?

I think using an height of 100% in the settings already achieve something better, as the top panel is not shadowed by the terminal (you only lose ~20px).

[dbuch]

Basically is think the setting for the console height would be better to have a percentage slide toggle instead of the pixels?

And then as a extra checkbox 'fullscreen' - Does it make sense?

[zzrough]

So just to be sure and summarize, this issue is about simplifying the preferences dialog only? You can use an height of 100% but having a simple "full screen" choice would be easier?

So this is a slight improvement on the preferences side. I'll try to improve the situation, this is not so easy as some users want it in pixels and other in %. I might add a button "Use all available space" or "Full screen" next or underneath the input area to simplify things up.

When I wrote the preferences panel, I hesitated a lot to add a hint label with the possibility to use an height in pixels or % as it would have been discovered more easily (this is a tooltip on the field at the moment). Maybe this can be enough, I do not know...

The problem is that if I put a slider, you need an other field for the size in pixels, plus a button for full screen ... it becomes cluttered, plus it complexifies the settings just for an height?

I'll keep the issue around and will post if I can get to an elegant solution.

[dbrunmeir]

the best widget for this kind of thing, is this: http://imgur.com/Hgklz

BUT: I would consider switching away from pixel based size. It's just not a good solution to fiddle with single pixel values. Also, at the moment you can make a bigger terminal than you have vertical pixels (e.g.: my laptop has 1366x768px, I just set the terminal to 900 pixel. this shouldn't be possible and is a bug).

My first suggestion is percentage based size. The easiest solution.

Another possibility would be to measure it in lines. A standard terminal has 24 lines, this should be the minimum. you would have to computate a maximum size for the different resolutions, with different font sizes. This could become a little complex, for example in a multi-monitor environment, in case of switching resolutions, etc, etc. This is my prefered solution though.

Also chose one solution and stick with it. Keep it simple, don't try to to implement a parser for different inputs (e.g. 200px, 100%, 2inch), it will become a mess, trust me. :-)

[dbuch]

I agree with katastrophal. That widget with 10 or 5 percent steps would be great.

[Hemlock]

Just to add some more noise... What is preventing you from just allowing the window to be resized? I have a similar project that I wrote (because I'm forced to work in Windows at work) and making it resizable makes it really easy to use.

[zzrough]

katastrophal: I initially added pixel based size because I wanted to have a pixel perfect vertical alignment, well ... for myself, since I'm the first user of the extension, and because it was quite a usual unit in other drop down terminals :)

You definitely are right that using a size in pixels is not very user-friendly, and I made some tests after my recent padding computation fix, and I can definitely adjust the height to be pixel perfect depending on the font height.

Now, I do not think using a line count is that nice:

• it's the same as pixels, this is an absolute value, so if you change for a higher resolution (large monitor or TV output, temporary), the height will be ridiculously small, and in the other way if it is lower, it might be taller than the new display height so it must be capped (but what's next: do I impact the line number? I do not think so)
• I suppose some users are interested in setting the number of lines because some terminal-based applications might not fit. But nowadays, most terminal-based applications can resize gracefully (curses-based apps, file listing, logs, etc.) and once the user feels the window is tall enough, I believe he does not care if it is 44 or 45 lines precisely.

On the other hand, with %-based height:

• it is already implemented (cool for me :-p)
• it indeed solves dbuck initial request, as you can specify full screen size (100% being a "special value")
• it will always works no matter the resolution changes

So, I think I'll do this to smooth out the experience:

• prefs: remove pixel-base input
• prefs: use a spinner widget like you suggested (capped x% - 100%)
• prefs: I could add a hint label to simply tell how many lines the specified % translates to
• except for 100%, I could adjust the height just a bit to always have pixel-perfect vertical alignment

That would solves everything, simplify the UI and might be a reasonable work without increasing complexity?

Hemlock: I do not want the window to be resizable. From the very beginning, I wanted the window to feel part of the shell itself/integrated, and not a regular application window, thus there is no app menu (see #7), you do not see the window in alt-tab, etc. If it's resizable, mutter let you also update the position, putting the window in middle of the screen or even off-screen and have fun of the terminal like it's a toy, which I did not like in other similar terminals (yakuake, guake, etc.)

[dbuch]

Exactly, the percent-based height solves the different resolution plus it seems more user-friendly indeed. true win/win - perfekt.

[dbrunmeir]

sounds good to me, thanks a lot. :+1:

a little off-topic, but I figure you want this extension to be simple and beautiful. I think a tabbed interface would just increase the complexety for little gain.

[zzrough]

katastrophal: I explained my current mood on the subject in issue #9. Indeed, a lot of people seems to encourage me not to do it. I was using "stjerm" and from time to time, for short work sessions I was kind of happy with tab support myself (and each time came back to no tab).

Now, I think using this extension and a gnome-terminal for longer work sessions (even just a bit longer) make a wonderful duo. We are talking about advanced users, so Super key, type "term", Super+up, and a maximized terminal is already here.

You're 100% right I'd like to keep it simple. If I'd ever implement tab support, I would never clutter the default experience. I indeed want to feel the terminal very well integrated to the shell, sleak, simple, fast. So thanks to be part of the ones telling me to keep it simple.

At the same time, a lot of users will not use it just for that and there will be someone tempted to fork it. Not that a big deal, I'm really fine with the concept, but I think there are too many duplicate extensions already and I already see a lot of unmaintained software.

Well, I'll see what I do about that, and if I have the motivation to do it, as it is also much work. My first option at the moment is delay it ;-)

Please note I just commited support for a custom command to be able to run alternative software that surely will handle tabs way better than I ever will (see 53d3195974592dbfcdab22820cddf36f104d8d7c).

[ElijahLynn]

Crosslinking https://github.com/zzrough/gs-extensions-drop-down-terminal/issues/47