[ubuntu-studio-devel] Next cycle

lukefromdc at hushmail.com lukefromdc at hushmail.com
Thu Apr 13 21:32:34 UTC 2017

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, 
>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 
>> desktop, that has come back in. IMO this is bad for audio use at 
>> (anything auto is). However, I realize I am audio centric. How 
>> this align with graphics/video use which are in general not real 
>> or low latency tasks.
>Yes, it is best for design/art people to have automount (its 
>hard to bring design/art people to unfamiliar ground, more 
>behavior, the better), turning it off could be a good addition to 
>-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 
>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 
>> 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 
>> broken. I would guess this not just a Studio problem... though 
>if it
>> is then the solution must be hanging around already. Needs study 
>> any case.
>considering autoupdates fixes security issues among other things I 
>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 
>> 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 
>> and enable hover so that click on category is not needed. I 
>> 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 
>> 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 
>> things I like in a theme:
>>     The window with focus stands out - menu bar is a different 
>>     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 
>> and see which is focused are important.
>> I understand that xubuntu is aimed at mainstream either browsing 
>> 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 
>> 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. 
>+ 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 
>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 
>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 
>(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 
>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 
>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 
>> DPI centric themes available? While I do not use a high DPI 
>> (mine are only 1600X900), I would expect both graphics and video
>> creators to use them... actually it would be very nice for 
>> too. SO at least two themes one for low and one for high, but 
>> 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 
>app scaling is also an issue and while some desktop environments 
>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 
>said, a theme that doesn't require a magnifier to see the icons 
>still be a nice step forward through :)
>> Normally artwork changes for LTS releases (next year) but as 
>> 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 
>> in a dual monitor configuration. I am sure that I have not been 
>> 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 
>> 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 
>> 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 
>and have been already thinking on some background ideas. :D I like 
>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 
>> changes will be to upgrade the pulse-jack bridge. The main thing 
>> to allow pulse to run at a higher latency than jack so that the 
>> will take less cpu and things like skype will continue to run 
>> with jackd at 16/2. Basically, I want jackd to look like a sound 
>> 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 
>> so nice, but we don't have a team of coders and 10 years to do 
>possibly silly question, would this still allow a change of 
>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 
>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 
>> the connections window (I may even be able to get -controls to 
>> 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... 
>> 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: 

More information about the ubuntu-studio-devel mailing list