| OvenWerks | zequence: Installed xubuntu-core for a look see. Just installing our Audio meta and menu stub. | 07:53 |
|---|---|---|
| OvenWerks | It looks like it could be a good starting place, but we may want to add a "utilities" meta for tools we keep that are not part of any of the work flows. parted, gedit, taskmanager, synaptic, whatever. | 07:56 |
| zequence | I'm thinking either that, or lubuntu-core could be a nice foundation for a formal Ubuntu Studio DE setup | 14:18 |
| OvenWerks | zequence: lubuntu-core would be harder to work with. In my tests of dropping our metas on top of different DEs lxde was more work to get working. | 14:47 |
| OvenWerks | xfce also has a more "modern" look and feel. | 14:48 |
| OvenWerks | zequence: lxde will be getting changed to qt libs (in progress) so the time to use that would be after all that work is done. | 14:50 |
| OvenWerks | zequence: Also, I think xfce is still the closest thing to gnome 2. | 15:00 |
| OvenWerks | lxde feels to me like half way between fvwm and gnome2. | 15:04 |
| zequence | gnome2 for me is not relevant. Just that it works. What is hard to get working? The menu? | 15:08 |
| OvenWerks | The menu is not really any harder to make work. | 15:09 |
| OvenWerks | A new app takes longer to show up on the menu at all because the menu is(or was) updated by a separate app that dooes nt run all the time | 15:10 |
| OvenWerks | There is a smothness to xfce that is not there in lxde. | 15:11 |
| OvenWerks | gnome2 like is not an issue no, it is the smoothness of use I was talking about. | 15:11 |
| OvenWerks | lxde has a focus on being small, and for that something(s) have to be given up. | 15:12 |
| OvenWerks | lxde shines in less than 1Gram systems, but in our case our apps generally demand more than that anyway. | 15:13 |
| OvenWerks | The de in our case is not a big part of what is in memory or on disk. | 15:14 |
| OvenWerks | zequence: so unless a new DE is easier to work with for the user, I would not go that way. | 15:16 |
| zequence | OvenWerks: If we offer all the other DEs, much of your arguments are already covered | 15:26 |
| zequence | And could be there is no need for a default DE at all | 15:26 |
| astraljava | zequence: What's the general consensus about how we would be "offering" the DEs? Are we talking about the -desktop packages? | 15:39 |
| OvenWerks | astraljava: in most cases a desktop package is not needed/wanted | 15:41 |
| OvenWerks | Take the case where the user already has their desktop the way they want it, we don't want to/ mess with it | 15:42 |
| OvenWerks | Once the user has logged in once after install and then adds Studio to the mix... their desktop is already set and any default changes we would make would have no effect anyway. | 15:43 |
| astraljava | OvenWerks: Oh ok, so we're talking about a reverse process here. Thanks, got it. :) | 15:44 |
| OvenWerks | zequence: yes, Te user can choose which they like. For our main ISO (if we had one) it needs to be polished/up to date looking, but at the same time not get in the users way. | 15:46 |
| OvenWerks | That is function well on systems a little older (3 to 5 years not worrying about 10 years) | 15:47 |
| OvenWerks | astraljava: There are two scenerios, 1) Studio is part of the DEs install and 2) instaling Studio after wards. | 15:48 |
| OvenWerks | astraljava: Installing Studio afterwards is likely to be done first because it is a lot less work. (mostly there now) | 15:49 |
| OvenWerks | In general, DEs are changing away from being menu based, or at least what menu is left is less capable. | 15:51 |
| zequence | OvenWerks: What do you mean by 1)? Which DE? | 15:53 |
| OvenWerks | xfce and KDE still have a good "classic" menu available if the user wants it, but Unity and gnome session (or is it screen) tht is not the case. | 15:53 |
| OvenWerks | zequence: I mean making the DE a choice at install time | 15:53 |
| zequence | You can add a classic meny to Gnome pretty easily, if you want it though | 15:53 |
| OvenWerks | Yes but the classic menu on gnome does not handle multilevel menus like ours | 15:54 |
| OvenWerks | (last I looked) | 15:54 |
| zequence | I'm thinking we ship one DE on our ISO, but adjust our installer so that the user can choose to install other DEs over the internet, replacing our default choice | 15:54 |
| OvenWerks | Yes, that was what I thought when I described 1 above | 15:55 |
| OvenWerks | In that we are on the same/ page :) | 15:56 |
| OvenWerks | But having a classic menu option is not really the issue, the main thing is that people are moving away from the menu thing and I think Studio needs to rethink how we present our big chunk of applications in a menuless world. | 15:58 |
| OvenWerks | It seems having a freedesktop menu splice does not reall work well in the DE world. The xdg standarrds are not well supported/broken/not going to be fixed. | 16:00 |
| * OvenWerks has filed bug reports for all the broken ones and seen them all shoved aside. | 16:01 | |
| zequence | That is why I was working on the categories thing about a year ago | 16:02 |
| OvenWerks | zequence: my latest thought is back to the workflow applet | 16:03 |
| OvenWerks | zequence: I agree. | 16:03 |
| zequence | One should be able to easily find applications by using simple search terms | 16:04 |
| OvenWerks | a workflow applet that sits in systray would work the same in all DEs | 16:04 |
| OvenWerks | Finding an app is one thing, knowing what you have is another | 16:05 |
| zequence | IT's not hard to do that either on any DE | 16:05 |
| zequence | On Unity it is quite simple to filter all of your applications by using categories | 16:05 |
| OvenWerks | Almost all DEs now have an app search yes. | 16:06 |
| zequence | Gnome has simplified by just showing all applications | 16:06 |
| OvenWerks | Sounds adroidish | 16:06 |
| zequence | In this respect Gnome is harder | 16:06 |
| zequence | Yes | 16:06 |
| OvenWerks | :P | 16:07 |
| zequence | I'm thinking it is better to show what tools to use for which use by documentation and videos, rather then using DE tools | 16:07 |
| zequence | All though, I'm quite fond of the idea of a workflow app too | 16:08 |
| zequence | I'm actually working on -controls right now | 16:09 |
| zequence | Seems I always do when sitting in a train | 16:09 |
| OvenWerks | A workflow app is something for the new user mostly... though I would tend to use it as a menu if the DE didn't have one ;) | 16:09 |
| zequence | I could imagine using a workflow application myself, if it was smart enough | 16:10 |
| OvenWerks | would you see that as part of a controls app or separate. | 16:10 |
| zequence | Separate. Controls is just for the core functions | 16:11 |
| OvenWerks | I personally would see it as two systray apps | 16:11 |
| OvenWerks | But then I would see controls as two parts: operational and setup | 16:11 |
| zequence | If it's just for replacing a menu, then it's in my view a menu, be it in the systray or elsewhere | 16:11 |
| OvenWerks | Making it smarter than just a menu would be nice, but I can't think how right now. | 16:12 |
| zequence | -controls has a menu for controlling jack and pulse, plus shortcuts for opening other things, like mixers and also "settings" | 16:12 |
| zequence | The settings application will have a separate starter, but you'll be able to open it from the controls systray menu | 16:13 |
| zequence | My first version will just be a simple settings application. No systray menu | 16:13 |
| OvenWerks | Ok that sounds good. | 16:13 |
| zequence | Right now I've been trying to figure out a good way for analyzing PAM settings | 16:14 |
| zequence | The idea is the settings application will be able to remove duplicate bad settings from any relevant file | 16:15 |
| OvenWerks | settings has to be there for adding Studio metas to already installed DEs | 16:15 |
| zequence | I'm thinking we could add a shortcut for the meta installer in the menu | 16:18 |
| zequence | I'm going to be using a new group for rt settings. audio is not to be used in the future, so I'll use something like jackuser instead | 16:18 |
| OvenWerks | zequence: I would like to see jackd run from login as default sound device. have pulse feed jack by default. I have been doing this on bth my Studio machine and my wifes desktop for over a year now | 16:19 |
| zequence | We could add that to the audio-core meta | 16:19 |
| OvenWerks | It works well | 16:19 |
| OvenWerks | Pulse can be turned "off" by unloading the pa-jack bridge. latency can be changed on the fly so at login latency can be long and shortened for lowatency work. I set things up so that pa turns off below certain latencies. | 16:22 |
| OvenWerks | With using the bridge removal technique, pa switches to dummy sink and all of the desktop apps can still work without hanging, but no sounds of course :) | 16:23 |
| holstein | i have a general question about that.. what about a user with a USB audio device? | 16:23 |
| holstein | would it address the labeling? etc? would it "just work" for them? | 16:24 |
| OvenWerks | My wife uses a USB device, no problem | 16:24 |
| holstein | i think removing jack from the equation is a good move | 16:24 |
| OvenWerks | The only place it may be a problem is plugging and unplugging | 16:24 |
| holstein | having it already running is a nice way to do that.. if it makes it easier.. | 16:24 |
| holstein | OvenWerks: oh.. that makes sense.. | 16:25 |
| OvenWerks | In my opinion a USB audio iF should be plugged in from before boot. | 16:25 |
| zequence | To get plug and play, someone will need to create a server for restarting jack | 16:25 |
| OvenWerks | jack does not need to be restarted | 16:26 |
| zequence | To change IF | 16:26 |
| holstein | OvenWerks: i like that as well, its just that, its not the "norm" for users coming from other platforms.. not that that need to be a consideration.. its just largely why folks dont adopt | 16:26 |
| OvenWerks | That can be done with jack_control | 16:26 |
| holstein | they have something that worked a certain way, and they want the *exact* same work flow, for no $$.. there may be little to do to address that, anyway | 16:27 |
| OvenWerks | jack_control can change IF without stopping | 16:27 |
| holstein | jack running from boot is personally something im not interested in, but, if i were just coming to the platform, i would appreciate it, and i think its a great idea | 16:27 |
| zequence | jackdbus does not stop, but it won't change IF automatically | 16:28 |
| OvenWerks | holstein: not from boot, from login | 16:28 |
| zequence | Also, will it crash? | 16:28 |
| holstein | well, boot, login.. you know what i mean | 16:28 |
| holstein | for an ubuntustudio user, they likely dont boot without logging in.. | 16:28 |
| OvenWerks | I have changed lots of things with out first stopping jackdbus. | 16:28 |
| zequence | USB devices are meant to be plug and play, so you can't really blame someone for using them as such | 16:29 |
| holstein | yeah.. its implied about USB hardware that you can remove them | 16:29 |
| OvenWerks | Yes, that is true. USB will get plugged in and out. | 16:29 |
| OvenWerks | same with FW | 16:29 |
| holstein | but, even if we put that in some documentation, it wouldnt necessarily be noticed, or understood.. | 16:29 |
| OvenWerks | I have switched from alsa to net with no problem though | 16:30 |
| holstein | could be a detraction.. "dont plug and play your plug and play device".. could be seen as a shortcoming | 16:30 |
| OvenWerks | internally, I think jackdbus does do a restart. | 16:30 |
| OvenWerks | PNP can still be done so long as the control app will scan for new devices. We should see how pa does that | 16:32 |
| OvenWerks | holstein: I agree PnP still has to work, I just haven't taken the time/effort to make it so in my case. | 16:37 |
| holstein | eh.. i dont know that its something that needs to be considered specifically | 16:37 |
| holstein | i dont think it should hold up your work, for sure | 16:37 |
| OvenWerks | jack_control is not well documented, there is no man page and jack_control --help/-h do not work | 16:38 |
| zequence | would be nice if jack behaved like PA | 16:38 |
| zequence | But, there is a slight problem with connections | 16:38 |
| zequence | Going from 8ch to 2ch | 16:38 |
| OvenWerks | yes. | 16:39 |
| OvenWerks | As I said, I think when changing back end, jack is restarted internally and so all connections are reset. | 16:39 |
| OvenWerks | I think also we need to have some sort of kill for it in case it hangs. | 16:41 |
| OvenWerks | detecting a running jackd and being able to kill that also makes sense. (in my case I have chmod -x jackd) | 16:42 |
| OvenWerks | I have had to actually kill jackdbus only a few times in the year and a half I have used things this way. | 16:46 |
| * OvenWerks thinks all of them have been with the USB device | 16:47 | |
| OvenWerks | zequence: holstein I would like to disable the pulse alsa module so that pulse just acts as a desktop front end for jack. | 16:54 |
| holstein | OvenWerks: sounds like a plan.. | 16:55 |
| zequence | OvenWerks: Doing that permanently would be bad, I think | 17:48 |
| zequence | We need a dbus server of our own, or something else, that can disable/enable start/kill/stop stuff in the way you would want to | 17:49 |
| zequence | Might actually be best to add all of that into a PA module | 17:49 |
| zequence | Perhaps the one that already exists. Adding config options for it | 17:49 |
| OvenWerks | zequence: Sounds like a plan. I hadn't thought of that, but KDE does that already so it is possible and yes the better way to go. | 18:05 |
| OvenWerks | BTW I posted a quick overview of jack_control in the mail list. | 18:05 |
| OvenWerks | zequence: for that matter we could incorperate the internals of jack_control into our own app as well. jack_control is a script I think anyway. | 18:07 |
| zequence | It's a python script for controlling jack through dbus | 18:08 |
| zequence | I've been using it as an example for a few things | 18:08 |
| OvenWerks | zequence: I had forgotten there is a pactl (I think... something close) that does for PA what jack_control does for jackdbus. I do not know if it is a script as well or not. But it does seem to control just about everything as well. | 19:10 |
| zequence | Not a script, and doesn't use dbus. But is similar, I suppose | 21:23 |
| OvenWerks | zequence: pactl is the one I use to un/load module-jackdbus-detect. Almost everything PA does is as part of a module, so removing a module stops that functionality as well. The problem is there is by default an autoloader, so removing a module may see it just reload. | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!