Ross, Thanks so much, for doing this. I am adding some comments here in this email. I can also reflect changes to the blueprints accordingly, but posting them here first, in case there is anything else that needs to be discussed before changing. I hope this helps. :)
Best Eylul ------ 1) https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-mounting-a This looks mostly good to me. My original comment was that it is more intuitive for non-audio users to auto-mount but that if this causes errors for the audio users (rather than a minor inconvenience or extra step) then we should remove it. I also mentioned ability to turn auto-mount on and off easily would be a good addition to ubuntustudio-controls. which could be its own blueprint if we accept it, or added to the -controls blueprint. 2) https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-updating-a This needs revision. Disabling auto-updates should NEVER be the default, period. It would leave users system vulnerable to attacks. Users can turn off the auto-updates if they want to.(Go to "software&Updates" -> "Updates". You can change how often the system checks for updates, it currently only downloads and installs automatically security updates, and displays the rest.) Advanced users can make that choice. It is not ours to make. The issue is the leftover kernels, and how to clean them. (so the blueprint should probably reflect that, rather than being about auto-updating) Len asked me before what is my current efi is looking like: my /boot/efi section is currently using 29mb out of a much bigger area. I cannot look inside at the moment (I need to look up how to do that) I recently ran autoremove through. It looked like it was removing some of the old kernels. (I am not sure if running autoremove risks breaking the system by accidentally deleting another package, assuming this works). Either way never ran into any issue related to this nor did I hear anyone ever having any problem with this. So my suggestion is to really let this be. (unless we happen to stumble upon an elegant solution to remove them) Either way, not everybody who uses this distro are developers or very experienced users. So pllease no disabling auto-updates for security updates, that is a VERY bad idea. 3) https://blueprints.launchpad.net/ubuntustudio-dev-tools/+spec/package-tracker-a No problems that I can see (does this also mean we are moving our package versioning system to git, or is that separate?) 4) https://blueprints.launchpad.net/ubuntustudio-controls/+spec/improve-controls-a This looks like what Len recommended we do before, but then again, not my expertise area. 5) https://blueprints.launchpad.net/ubuntustudio-look/+spec/new-wallpaper-a This looks good to me. I volunteered for doing this (unless somebody desperately wants to) Original discussion was to have these ready for 18.04, but I can adjust to have them ready by 17.10. Just let me know which deadline I am working toward and I'll make it. 6) https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/change-default-theme This looks good to me. In terms of HiDPI, we can add a separate blueprint about reviewing other problems encountered in HiDPI. (in preparation for solving them by 18.04 latest) the discussion earlier was a more long term issue review: - Lack of scaling on OS level by application means many programs are nearly unusuable. (old GTK2 software that is not maintained, and anything java based being the biggest problems right now - and no avoiding them is not a viable option at the moment :) ) - GTK3 has better support for HiDPI - GTK2 has SOME support for HiDPI (and ardour is not switching to GTK3) All I can think in terms of actionable items is that a) we should probably use GTK3 for any new code we write/maintain as UbuntuStudio b) keep an eye on ardour and any other software that uses GTK2 to file bugs if they are well maintained, or find replacements. Anything beyond that is probably out of the scope of what we can do. -------- On 05/15/2017 11:31 PM, Ross Gammon wrote: > And I forgot to say - it would be great to add suggestions to them and > especially links to useful resources on the web, so anyone can pick > one of the tasks up and "have a go!". > > > On 15/05/17 22:28, Ross Gammon wrote: >> OK - I have done the first draft of some blueprints for the Artful >> 17.10 release based on Len's list. You can see them listed (with >> links) under the "Current Development Release" section here: >> >> https://wiki.ubuntu.com/UbuntuStudio/Blueprints >> >> Alternatively, you can access them using the dependency tree on this >> page: >> https://blueprints.launchpad.net/ubuntustudio/+spec/ubuntustudio-topic-a >> >> I had some troubles incorporating all of the feedback from eylul & >> lukefromdc, and summarising Len's ideas. Therefore, I would >> appreciate some review and tweaks before we fill in the Workitems >> part for each of them according to >> https://wiki.ubuntu.com/UbuntuStudio/ManagingBlueprints#Workitems >> >> Cheers, >> >> Ross >> >> On 22/04/17 12:03, Ross Gammon wrote: >>> Thanks for doing this Len. >>> >>> On 04/13/2017 05:49 PM, Len Ovens wrote: >>>> Aside from having a new -controls (I hope) there are a few things I >>>> would like to hear about. >>> I have re-targeted the last controls update that missed Zesty, to >>> Artful. If you spot a potential sponsor on IRC, then please point them >>> at the bug (I will be a bit busty this week). >>> https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-controls/+bug/1678316 >>> >>> >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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) >>>> >>>> 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? >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> -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. >>>> >>>> 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 ;) ) >>> I will start turning these into blueprints over the next few days >>> (including the input from the subsequent emails in this thread). In >>> controversial areas I will phrase it something like "try ....". We can >>> always revert if people aren't happy. Although it will be easier to >>> revert if we work in a feature branch this time :-) >>> >>> For me, I really want to work on a package tracker so that we have a >>> place to look to see when our packages are out of date or buggy. I >>> would >>> also like to do some sort of Bug Hugging days where we can encourage >>> more people to be able to triage bugs and take the first steps to >>> identifying fixes. Basic bug triaging I can do, but triaging >>> audio-video >>> stuff is tricky, especially when it can depend on hardware and >>> sensitive >>> settings. It would be great to spend a day here and there on one of our >>> priority packages, and as a team sort out all the bug reports so that >>> they are either confirmed or rejected, passed upstream where required, >>> and potential patches identified that someone might turn into a SRU >>> (Stable Release Update). >>> Cheers, >>> >>> Ross >>> >> >> > > -- 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
