*nods* GTK2 and java are the 2 major desktop env. independent culprits, from what I can tell, which unfortunately are still around in many applications.
Eylul On 04/14/2017 12:32 AM, lukefro...@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" <ey...@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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel > -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
