[ubuntu-studio-devel] HiDPI (previously: Re: Next cycle)

eylul eylul at ubuntustudio.org
Thu Apr 13 22:50:23 UTC 2017

*nods* GTK2 and java are the 2 major desktop env. independent culprits,
from what I can tell, which unfortunately are still around in many


On 04/14/2017 12:32 AM, lukefromdc at hushmail.com wrote:
> GTK3 itself brings hidpi support to its widgets. That means GTK3 desktops
> should support it. I only have 1920x1080 as my largest monitor, but GtkInspector
> allows testing hidpi scaling, with 1.0 and 2.0 times default size options. I can
> verify that this works in MATE for mate-panel and Caja (desktop/folder icons) 
> though double-sizing everything runs out of space fast on my monitor.
> GNOME (Ubuntu default), Cinnamon, and now MATE all use Gtk3 and should
> all offer at least partial hidpi support. Not sure if this works for everything, and
> Gtk2 apps will remain problematic no matter what the desktop environment.
> On 4/13/2017 at 5:10 PM, "eylul" <eylul at ubuntustudio.org> wrote:
>> Len thanks for this. A lot of interesting thoughts here. Opinions, 
>> etc
>> ahead. :)
>>> Auto mounting - we used to make sure there was no auto mounting 
>> of USB
>>> drives, cds or dvds. But since we have started borrowing 
>> xubuntu's
>>> desktop, that has come back in. IMO this is bad for audio use at 
>> least
>>> (anything auto is). However, I realize I am audio centric. How 
>> does
>>> this align with graphics/video use which are in general not real 
>> time
>>> or low latency tasks.
>> Yes, it is best for design/art people to have automount (its 
>> already
>> hard to bring design/art people to unfamiliar ground, more 
>> intuitive
>> behavior, the better), turning it off could be a good addition to 
>> the
>> -controls through if it is feasible? If not I think it is worth
>> discussing pros and cons and more details on what the problem is. 
>> If it
>> is seriously hindering audio creators, I'll take not hindering one 
>> side
>> in price of being a bit less intuitive to other side.
>>> Auto updating - same as above. But to add to it, I noticed that
>>> autoupdating installs new kernels in background. However, there 
>> seems
>>> to be no background old kernel clean up. I don't use efi myself, 
>> but I
>>> understand that efi uses a separate boot partition of minimal 
>> size and
>>> could become full with no warning... perhaps making updates or 
>> booting
>>> broken. I would guess this not just a Studio problem... though 
>> if it
>>> is then the solution must be hanging around already. Needs study 
>> in
>>> any case.
>> considering autoupdates fixes security issues among other things I 
>> would
>> go with they need to stay. In terms of the kernel issue, I do use 
>> efi, I
>> never ran out of space in that manner until now, but still filing 
>> a bug
>> about this could be useful?
>>> whisker menu - I still hate it :) But if we are going to keep it 
>> (I
>>> always go back to the system menu on my systems) can we at least
>>> resize it so that the menu categories are all visible by 
>> default...
>>> and enable hover so that click on category is not needed. I 
>> understand
>>> that having the search window there is nice for some people... 
>> but I
>>> just don't seem to come up with valuable search terms ever... my 
>> brain
>>> and whoever sets seach data just don't match. (probably means I'm
>>> abnormal)
>> My personal disagreement with this aside (I actually use the 
>> search bar
>> to launch a program often) :D I would caution against hover in
>> particular as it is a gesture that is inaccessible to touchscreens
>> (which are becoming more and more common on laptops). I assume 
>> this is
>> why whisker went with this approach actually.
>>> Can we change the default theme to Moheli or similar? There are 
>> two
>>> things I like in a theme:
>>>     The window with focus stands out - menu bar is a different 
>> colour
>>>     The border needs to be wide enough to be easy to grab
>>> More than one workpace by default - I understand that I may work 
>> a bit
>>> different than others doing development on more than one project 
>> at a
>>> time. It is not unusual for me to have 30 or more windows open 
>> at one
>>> time. IDEs do try to make things so this is not needed... but my
>>> workflow is just that way. This is why being able to resize 
>> windows
>>> and see which is focused are important.
>>> I understand that xubuntu is aimed at mainstream either browsing 
>> or
>>> one other app fullscreen use and so the desktop we end up with
>>> reflects that. As content creators, how do the rest of us set up 
>> their
>>> desktops? Should changes be made? or am I really the odd one out?
>> for me as an artists its usually only one, or two windows (e.g. 
>> drawing
>> + reference image), and often 2 windows means 2 screens if 
>> possible. (at
>> least that has been my experience so far). I need the screen 
>> estate to
>> see what I am doing, more often than not. When doing creative 
>> coding it
>> ends up more of a mess with language references, and code and 
>> preview
>> window etc. :) Usually through if I have 20 windows up, it is 
>> because I
>> have been getting distracted and doing 3 things at once (for which 
>> now I
>> am trying to use workspaces and KDE activities) Window focus/menu 
>> bar
>> aspect is not critical for me in either direction but hard to grab
>> borders are an issue regardless of how many windows one work with 
>> tbh.
>> (I have been using my own window styling in XFCE for a while now 
>> so I
>> didn't realize this was still a problem) TLDR, wouldn't oppose 
>> switching
>> themes if it will improve usability.
>> I am going to side track here, and say, combined with the previous
>> point, it might be a good idea for us to discuss how EXACTLY we 
>> use our
>> desktop and share experiences at some point and even reach out to 
>> our
>> users if we get the chance. That way we can hopefully find out 
>> what are
>> bottlenecks for a lot of people in terms of efficiency and what are
>> diverging personal choices. :)
>>> Also in the world of themes. Are there any high DPI or better 
>> variable
>>> DPI centric themes available? While I do not use a high DPI 
>> monitor
>>> (mine are only 1600X900), I would expect both graphics and video
>>> creators to use them... actually it would be very nice for 
>> mixbus-32c
>>> too. SO at least two themes one for low and one for high, but 
>> better
>>> one that can deal with making fonts visible at any dpi.
>> I have been using a laptop with HiDPI screen for past few months 
>> and I
>> had to quit XFCE altogether, icons and themes aren't the only 
>> problem,
>> app scaling is also an issue and while some desktop environments 
>> are
>> better than others about this, none that I have seen has full 
>> support of
>> HiDPI, so this is somewhat of a difficult problem to solve. That 
>> being
>> said, a theme that doesn't require a magnifier to see the icons 
>> would
>> still be a nice step forward through :)
>>> Normally artwork changes for LTS releases (next year) but as 
>> things
>>> move slow here... maybe now is a good time to start thinking 
>> about a
>>> new backdrop. It would be nice if there could be one that is
>>> extensible where a generic version could be used on the right 
>> monitor
>>> in a dual monitor configuration. I am sure that I have not been 
>> plain
>>> here :)
>>> I am thinking of a left monitor BG that is complete in itself for
>>> single monitor users. Then a second BG that looks like an 
>> extension of
>>> the left but with no logo etc. It may even seem blank or just 
>> continue
>>> the right edge colours or something like that. Then build the ISO
>>> install for a dual monitor setup with those two BGs as default (I
>>> don't thnk this would be too hard). If started up in single 
>> monitor
>>> mode, the system will reconfigure using the left monitor's BG 
>> and look
>>> right in that configuration as well.
>> this is something I can help with on design/art side (not that it
>> excludes anybody else from doing the same), :) its certainly more 
>> in my
>> area of focus than trying to learn packaging or do backend 
>> development
>> and have been already thinking on some background ideas. :D I like 
>> the
>> idea of an extended monitor layout.
>>> -controls will make some changes beyond what it does now and I 
>> want it
>>> complete and well tested for 17.10 so that we have time to make
>>> changes in it and the rest of the system for 18.04LTS. One of 
>> those
>>> changes will be to upgrade the pulse-jack bridge. The main thing 
>> being
>>> to allow pulse to run at a higher latency than jack so that the 
>> bridge
>>> will take less cpu and things like skype will continue to run 
>> even
>>> with jackd at 16/2. Basically, I want jackd to look like a sound 
>> card
>>> to pulse. I would like it to show up in pulse's configuration 
>> tab for
>>> example so people can set it up as more than stereo if they 
>> want. But
>>> the main thing is that the pa-jack bridge should never cause jack
>>> xruns... pa xruns are ok :P  pa hides it's xruns already (but not
>>> their artifacts) so go with the flow. A PA replacement would be 
>> ever
>>> so nice, but we don't have a team of coders and 10 years to do 
>> that.
>> possibly silly question, would this still allow a change of 
>> settings
>> when it is needful to record the pulseaudio output? because it 
>> would be
>> nice to not lose that option?
>> in terms of controls, I'd like us to have time to take a very 
>> critical
>> look at the UI once you are done with the features, so that it is
>> polished and intuitive, beyond that I like your plan. (again, 
>> thanks so
>> much for working on this!)
>>> My goal for -controls is to replace most of the aging qjackctl 
>> except
>>> the connections window (I may even be able to get -controls to 
>> open
>>> the qjackctl connections window) and to make it more like 
>> Cadence. I
>>> would use cadence if it was packaged and I totally agreed with 
>> the way
>>> it does things. (I am not saying cadence does things wrong... 
>> just
>>> that I can do better ;)  )
>>> -- 
>>> Len Ovens
>>> www.ovenwerks.net
>> -- 
>> ubuntu-studio-devel mailing list
>> ubuntu-studio-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

More information about the ubuntu-studio-devel mailing list