=== micahg_ is now known as micahg [02:35] zequence: I will try gnome3. Is it an ISO or from mini.iso? [02:35] OvenWerks: Either use the Ubuntu Gnome installer, or the mini.iso [02:36] I understand That there are many places a menu is not used. KDE also has modes that don't use a menu. [02:36] But it needs to be a current one, if you want to get Gnome 3.8 [02:36] That shouldn't be a problem as I have to download anyway. [02:36] I am finding out why the menuediting tools don't work. [02:37] There is a bug in the default xfce menu style (ours included) [02:37] The merge is done at the top of the file and should be done at the bottom. [02:37] Makes a big difference. [02:40] The bug seems to be in Xubuntu, xfce and lubuntu. [02:41] As well as studio... [02:41] KDE seems to be ok, I am not sure if it is because the menu file is right or they just use a different parser. [02:43] OvenWerks: So, you know of a workaround? [02:44] Ya, just move one line from the top of the file to the bottom [02:44] As it is in the KDE file (just looked) [02:44] OvenWerks: So this will make the menu work for all DEs? [02:45] The problem is the DE file is what is broken. So I have to do a bug report for all of the broken ones. [02:45] It is not just our menu, but the menu editors need it to work right [02:46] Question is, which way should it be? [02:46] top or bottom [02:46] And maybe both should work? [02:46] Bottom acording to opendesktop [02:46] ok [02:46] The merge should go below the stock one because the lowset setting is the one that works. [02:47] The bug should go to the DE itself. XFCE and LXDE in this case [02:47] I read the XDG page on merges a few times to figure out what was going on [02:47] The bug report, I mean [02:47] Yup, Studio too. [02:48] And, it would be good to do it both in Ubuntu and with the upstream developers [02:48] Well, Studio is not a DE [02:48] But if you mean, you need to fix a setting file, well ok [02:48] no but we use our own menu file. So it has to be right [02:49] Same with xubuntu [02:49] I think lubuntu as well, but I will have to check [02:50] I am not sure but I think lxde uses the xfce pannel, so fixing xfce may fix that [02:50] In either case, the most important fix is upstream [02:50] Yes. [02:50] I will have to check cinnamon and gnome3 classic [02:51] I need to find out which file in the xfce DE contains the stock menu file. [02:51] Which package. [02:51] I've started a discussion on pkg-multimedia-maintainers list about separating jackd from jackdbus, but is seems someone is of the opinion they should not conflict with each other [02:52] at least, I'm going to try separate them into different packages this cycle [02:53] It's really wrong to have three versions of the same thing, with no real upside to it [02:53] Aren't they buiolt from the same src? [02:53] Yes, jack2 source [02:53] Can you set the target for just one? [02:53] You can build one source into multiple packages [02:54] jack2 is actually in multiple packages [02:54] jackd2 jackd2-firewire, etc [02:54] but not jackdbus [02:55] Another thing that bugs me is that from a user point of view, you don't see why you need three kinds of jacks. I mean, you know why you need jackdbus, but not why you need the others [02:55] So, the arguments are on such a technical level, that it has nothing to do with users [02:55] Right [02:56] For studio, dbus is best [02:56] some apps require it [02:56] and from what I understand, all jack apps support it [02:56] but if you are going to unload pulse or the bridge, then jackd might be fine [02:57] But to work right with pulse requires dbus [02:57] Actually, not sure if you can do everything with jackd2 as you can with jackdbus [02:58] other than getting the PA module auto create sink and source [02:59] The more important thing is getting pulse to release the port [02:59] Without that pule and jack on the same system is broken [02:59] *pulse [02:59] Well, that does happen with both jackd(2) and jackdbus [03:00] I was pretty sure it was a dbus function [03:00] No, it's something that works for jack2 in general [03:00] jack1 doesn't have that code though [03:01] for jack1, we'd need to add a wrapper script. Maybe one that looks for if pulse is using the same card, suspend it, then start jackd [03:01] it is a dbus thing [03:01] but jackd(2) does dbus too [03:02] Ah [03:02] But, I'm not sure at this point if some apps require jackdbus, like ladish [03:03] Ok, then why jackd? Or is jackd the same code as jackdbus called different? [03:03] Or does jackdbus control jackd? [03:03] This is the problem. It's on a technical level, that requires one to understand the application quite well in order to make an opinion of why one should be used over the other [03:04] Do any of the jackd2 devs use jackd over jackdbus? [03:04] I just know that from a user point of view, it's stupid [03:04] I know that las has very strong opinions about certain things [03:05] and it seems different people are controlling different sources [03:05] Or is it just there to satisfy old scripts? [03:05] no, I think some people prefer jackd over jackdbus [03:05] Yikes! [03:05] Jack3 anyone? [03:06] or just jack [03:06] Ya. [03:07] I wish gcdmaster had such supporters. [03:07] So far I had one response, from Rogin Gareus, who likes to use both during development, so that in my view is not something we need to support in packaging - since a developer could just build one of them locally [03:08] But, he also mentioned he likes to use many instances of jack with separate cards [03:08] however, I just think that why not just use jackd when doing multiple [03:08] but, also, I need to look more into what you can do with jack. which apps support what, and so on [03:08] I think that is for testing [03:09] running multiple instances can be good sometimes. but it should be easy to overlook, and control from a user point of view [03:09] I never have the need for multiple jacks myself though [03:09] Ya. [03:09] I can see the point in running jack with one card, and PA with another [03:09] and even ALSA with a third [03:10] And sure, being able to run more than one jackd won't harm anyone [03:10] but, why running both jackdbus and jackd? [03:10] I don't know if it is possible to run two jackdbus servers [03:10] me neither. I suspect not [03:11] so that would be the point of jackd then? [03:11] Well, actually, I wasn't able to run two jackd's just now [03:12] so, not sure how Gareus does it [03:12] You have to give each server a unique name. [03:12] "`default' server already active [03:12] Failed to open server" [03:12] Ya default is the default server name [03:12] ah [03:13] I learned that running netjack [03:13] yeah, now it worked [03:14] Netjack works as jackdbus too BTW [03:14] Easier too. [03:20] zequence: OK now you have two jacks, how does the application decide which to graph to? [03:21] OvenWerks: No idea :) [03:21] I was also able to run both jackd and jackdbus, but I think that's a bug [03:25] If they are both unique names it should be ok. [03:43] OvenWerks: start patchage - it'll start jackd automatically. start qjackct - jack is running. stop jack with qjackctl - appears to be stopped, but isn't. start jack with qjackctl - now both jackd and jackdbus are running [03:44] when restarting jack with qjackctl, it appears it starts jackdbus, but shows connections for jack, and probably, jackdbus is only running in the background, not dealing with audio at all [04:15] Fun fun. === astraljava2 is now known as astraljava [05:48] another round of kernels about to be released soon [05:49] this time, one of my builds was corrupted [05:49] probably due to faulty RAM [05:49] the error didn't appear until LP tried to build the package === cub_ is now known as cub [07:24] zequence, in the video player conversation you mentioned that there are blueprints for each workflow, are they available online? [07:25] cub: Yeah, just a sec [07:25] cub: Here's an overview of all of them https://wiki.ubuntu.com/UbuntuStudio/Blueprints [07:26] The actual blueprints exist at Launchpad https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-ubuntustudio [07:26] if you scroll down, you'll see a tree of bubbles [07:26] each "bubble" is a blueprint [07:26] hover your mouse over them, and you'll see what they are for [07:27] This is the meta blueprints, which contains all the workflows https://blueprints.launchpad.net/ubuntu/+spec/ubuntustudio-s-meta [07:29] Ah they are clickable. :) [07:30] thanks [07:43] cub: Yes, each blueprint includes workitems. That's the actual work that we do [07:43] anyone could basically just grab a workitem and start working on it [07:44] but, we prefer that people first go through a bit of a process with setting up their machines for development, and get an overview of how things work first [07:48] Yes, right now I'm trying to learn the process, what is workflow what does it look like and so on [07:49] just becoming aware of the blueprints is a major step into the right direction [07:49] well, workflows aren't really that specific [07:49] I mean, it's just a way to split things up [07:49] from a use case point of view that is [07:49] yes I thought it would be more like a user story [07:49] the idea came from our previous project lead, Scott Lavender. He really wanted to push for simplifying user interaction [07:50] And to do that, you'd categorize things according to use cases, instead of according to more technical terms [07:50] So, workflows are basically that. From the user point of view [07:50] makes sense [07:52] There's been talk of creating a workflow application. A side bar that would enable you to keep track of all the stuff you need for your workflow. And who knows, but we don't have any developers working on that. And not really anyone designing it either [07:52] So, for now, workflows are more about the metas that we have: ubuntustudio-audio, -video, etc. And our custom menu, which uses the same logic [07:53] If we could get more people working on things, they could work on one area alone, and not mind so much about what someone else was doing [07:54] So, if one works on video, they don't need to worry about audio [07:54] That's another reason to split things up [07:54] right now, the few people we have do a bit of this and that [07:54] there's no time to go into detail [07:55] at least not with everything [08:00] Quite interesting. I have been using US for so long but never had any thought I could actually help out in some way until now [08:05] doesn't need to be a big deal either. Some people of course needs to get deep into it, as the whole thing is quite a lot to keep track of. but, you can also just pick something that interests you, anything, and work at it for a couple of weeks, and then leave it [08:07] I'm here cause I hate when things don't work, and realized I could do something about it === cub_ is now known as cub === kubotu_ is now known as kubotu [13:29] zequence, is the new art head still on the team? I sent an email yesterday but no reply .... [13:29] cfhowlett: He is. What about? I'm sure he's just busy [13:30] I offered some suggestions and contact info for the 14.04 wallpaper. [13:31] ok. I'm sure he'll get back to you [13:31] zequence, fair enough. thank. [13:31] thanks. === ashams is now known as Guest15032 === kubotu_ is now known as kubotu === ubott2 is now known as ubottu === kubotu_ is now known as kubotu === kubotu_ is now known as kubotu [17:52] I'm getting some resistance in making jackdbus and jackd conflict [17:52] but, should be no problem separating them into their own packages === kubotu_ is now known as kubotu === ubott2 is now known as ubottu === holstein_ is now known as holstein [23:35] zequence: there may be some use caes where you might run both at once. (d and dbus)