[12:42] hi [12:43] i have been mindmapping a few ideas and questions, but i'm hesitating as to _where_ to bounce the map... [12:45] i find the wiki to be a great tool. is it ok to write a sort of.. ehm.. blurb there? :) [12:49] wrong time of the day :) [12:50] or night :D [12:58] sakrecoer: You could start with the mail list. I could point you in the right direction in the wiki, once I know what is what so to speak. [12:58] zequence: tahnks! === sakrecoer is now known as sakrecoer_idle === sakrecoer_idle is now known as sakrecoer [13:02] zequence: could we set a meeting here on irc sometime? many of the nodes and path in my mindmap are probably already deeply discucssed by you guys, hence i find it difficult to formulate by email.. [13:04] sakrecoer: I'm going to be here for the rest of the day pretty much, so you can bounce some stuff on me, if you like. Others will read the backlog and fill in later, no doubt. [13:04] cool! [13:05] i'm all tied up in the workflow brainstorm :) [13:05] i think its brilliant [13:05] but i wonder about its translation into menus [13:06] Yes, Scott - the project lead before me, is the one who started the whole aspect of workflows, I believe. [13:06] i feel the "graphics, photography, video and publishing" are all "visuals" [13:07] Sure. But, there are specific applications for all of them. [13:07] yes! [13:08] graphics is kind of broad [13:08] just like with audio [13:08] Yes [13:08] yet audoi is heavily subdivided [13:09] The audio workflow is not subdivided into workflows that much though. Only tool types. [13:09] i feel like mixing is to audio, what graphics are to "visual" [13:09] no! but it is in the menu [13:09] You mean mixers? [13:09] let me try that again :) [13:09] I understand the remark you made of mxing to audio what graphics is to visual [13:10] But, what subdivisions of audio workflows do you see in the menu? [13:10] the workflows should remain like they are, but i wonder about the translations of workflows into menus [13:11] if a selection was to be made from 2 roots: audio and visuals. i think half the path to menuless DE is paved. [13:11] i'm thinking purely on a interface level... [13:11] Each meny item has one or more categories [13:12] When you search for it in a menuless system, you can search on any of those categories [13:12] In a menuless system, one application can have many purposes, and you can search on any of the purposes [13:12] At least, ideally, it would be so [13:13] The current categories used in the menu are freedesktop categories [13:13] http://standards.freedesktop.org/menu-spec/latest/apa.html [13:13] i see.. [13:13] I would have liked to develop that. Make sure all the desktop files have correct categories, and invent new ones if needed [13:14] publishing is not a part from it? [13:14] ok [13:14] Don't remember actually. [13:14] I never had the time to get started on this myself [13:15] The menu we have now is populating the items using a custom list in the menu file [13:15] maybe taht link you gave me is old? [13:15] I would rather the meny was autopopulated from correct categories [13:15] It's old, but it's the standard [13:15] * OvenWerks would like that too. [13:16] well, it seems to me ubuntustudio is already breaking that standard? [13:16] There's also another system in the works, called debtags [13:16] Yes, but we did that before we started talking about freedesktop categories [13:16] ok [13:16] What we do is not only for Ubuntu Studio, but for all of Debian. [13:16] sakrecoer: if we don't "break" the standard then all the audio apps are one big mess. [13:17] i understand [13:17] https://wiki.ubuntu.com/UbuntuStudio/FreedesktopCategories [13:17] thanks! [13:17] https://wiki.ubuntu.com/UbuntuStudio/WorkflowCategories [13:18] These are just stubs more or less [13:18] The problem as I see it is that the standard has stopped moving or keeping up with people's needs. [13:18] its poorly updated... [13:18] yes.. [13:18] i would very much like to help you push it forward :) [13:18] Well, it's cause no one has been working on it :) [13:18] This too https://wiki.ubuntu.com/UbuntuStudio/Debtags [13:18] Part of that is that newer desktops are moving towards a more Android like experience. [13:19] So there is no push from big players to move the standard forward. [13:19] if you don't mind i would very much like to update the wiki, to be able to work from that. [13:19] i'm thinking this in 2 phases: [13:20] 1. synchronise wiki with current DE state of ubunstudio [13:20] 2. tweak it till it Hz :p [13:21] You are free to help with this work. One guy has been involved in this in the past, and should be aware of whatever changes you make though. [13:22] Let me get his name.. [13:22] Ross Gammon [13:22] It's enough you announce any work on the mail list, and he will know [13:23] Also, he might have opinions. He's been especially interested in the deb tags part [13:23] He's the guy who edited the pages last time [13:23] FreedesktopCategories and DebTags [13:23] zequence: is there a spec for debtags? [13:24] Nope [13:24] zequence: is there a format in the desktop file for them? [13:24] same as Catagories? [13:25] I don't remember what it was I was thinking before [13:25] Probably I wanted to sync the two [13:25] ..as much as possible [13:25] deb tags can be used to find software when you use a package manager [13:25] Not sure any package managers do that yet [13:25] Our installer could do that [13:25] i will reach out to Ross :) thank you [13:26] Let me find the email he sent on his last work. It was 10 months ago [13:26] https://lists.ubuntu.com/archives/ubuntu-studio-devel/2014-July/006016.html [13:26] ah great! :) [13:27] I think that could be all of what has been done so far on that subject [13:27] Ross did express interest in continuing the work, so just make sure to discuss or inform using the mail list, so he has the chance to catch up [13:28] of course! :) [13:28] I added the deb tags page to the Dev Side Bar in the wiki, so it's easier to find now [13:28] thanks! [13:32] sakrecoer: My idea of how we do things here is pretty similar to how Debian works. As long as no one has any objections to your work, we include it. If someone objects, or has counter ideas, we discuss it and try find the best option. [13:41] zequence: just reading about debtags... it appears they are not in the desktop files at all, but part of the package and stored in the *.deb file and therefore apt's cache. [13:42] This means it can be used for choosing a package to install, but might also be used when looking for an already installed package to run as well. [13:44] in the case where a package contains a colection of utilities, the debtags would relate to all of them and one hopes the desktop Categories helps sort things to an application level. [13:44] neither one of these things helps the cli user ;) [13:46] I suppose a cli browser could list commands included inside a package that matches a search though. [13:51] We could make ubuntustudio-installer use deb tags [13:51] zequence: we should. [13:51] Also, not sure about Unity and gnome-shell, and others that use search as basis. Could be they could use that too [13:52] zequence: the question may be what lib or utility browses that... do any of the apt tools? [13:52] But, yes, hard to add that to the menu, unless we have some sort of fancy script that generates the menu as a hook after each time someone installed something [13:53] Not sure. I never delved much deeper into that back then [14:18] zequence: I am seeing that we do not have a web page IDE at all. maybe we should include one. [14:19] zequence: in publishing maybe? [14:19] I was thinking the same thing, but that's not what you would usually call it I guess [14:19] We could include another workflow - development [14:20] Ya, but where does that one stop? [14:22] web page creation could be a sub use for all the workflows. [14:22] html and css could be seen as belong to some sort of graphics workflow, but I guess generally you'd put it under development [14:23] If we start a development workflow does it include tools for c? qt? gtk? cairo? [14:24] pure data is in part coding [14:25] supercollider too, though we don't include it, I tihink [14:25] yes and so is php and there are other things too. the question is how wide do we want to go? [14:26] jekyll would fit nice in webpage creating as it includes a webserver on :4000 [14:26] The installer does allow the user _not_ to install whole groups of packages or to cherry pick. [14:27] But, isn't jekyll more about content creation than development? [14:27] no, its about site devloppement [14:27] to create content for jekyll you need text editor or audio/video editor. [14:28] whats is interesting is that it is made for static websites in html(5) [14:28] I'm not against adding a development side to what we offer. Especially if the user has the option to not install stuff, as is the case now pretty much. [14:29] yes, indeed... i don't think jekyll is an imperativ in any way :) [14:29] but speaking of web publishing and audio visual: http://sourceforge.net/p/kid3/feature-requests/59/ [14:29] How much should be included in the ISO? [14:30] We have a lot of space. I would like to see a CD size ISO before we increase the current DVD size though [14:31] i remember there used to be a file tagger included before. i believe it was with thunar, but is there any ID3 tagging app by default in ubustu now a days? [14:31] It would be nice to include new things in an after ISO install desktop installer first. It would be great if it sent back stats as to what SW people actually install. [14:31] since i havn't found any, i've been a heavy kid3 user lately... [14:31] Is that for tagging audio files? [14:31] yes [14:32] Don't think anyone mentioned that at any time. Guess most of us don't use'em so much. I do sometimes, but tbh, hadn't thought about adding one [14:32] We should, I think [14:32] yes. [14:32] Ok, let me introduce sakrecoer to our feature specifications [14:32] Kid3 is my favorite, i've tried many... but it just an opinion. [14:33] :) [14:33] Generally we only include one application for each specific task. In some cases, we make exceptions [14:33] Many audio file creation apps will allow one to specify tags at creation time, but being able to modify them after is very worthwhile. [14:33] Like, we include both ardour and qtractor [14:34] sakrecoer: Feature specifications are called blueprints at launchpad.net [14:34] sakrecoer: Here's all of our blueprints so far for the X release (16.04) https://blueprints.launchpad.net/ubuntustudio/+spec/ubuntustudio-topic-x [14:35] Consider 15.10 a Beta of 16.04 [14:35] kdi3 is KDE? we do have some kde apps so it would not add much, but running a KDE app leaves extra kde BG stuff running after the app closes. So for a small app like this that is not the best. [14:35] The page you are looking at is the main topic. It has dependencies to all other blueprints further down [14:36] sakrecoer: This is the meta blueprint. It has dependencies to all of our metas https://blueprints.launchpad.net/ubuntustudio-meta/+spec/ubuntustudio-meta-x [14:36] yeah, i'v thought about that kde issue, its the downside of Kid3, i'm not superfond of kde... but the other ID3 taggers available in software center i haven't had very great experience with... [14:36] In the case of an audio file tagger, I would put it in ubuntustudio-audio [14:36] Someone doing Audio creation is not likely to be using kdenlive and so a kde file tagger would be the only kde app in the audio workflow. [14:38] thanks zequence :) [14:38] i've been wanting to ask about blueprint thing :) [14:38] How about kid3-qt? [14:38] So, I added a line on the Whiteboard for https://blueprints.launchpad.net/ubuntustudio-meta/+spec/ubuntustudio-audio-x [14:38] oh... thats the one i run ... hmm... [14:38] kid3-qt [14:39] sakrecoer: If you have further ideas on what to add to any of the metas, just put something on the whiteboard. [14:39] kid3-qt has no kde deps. [14:39] true... missed that completly... [14:40] thanks zequence! [14:40] sakrecoer: The first few weeks we do feature definition. There's a rough schedule here https://wiki.ubuntu.com/UbuntuStudio/DevelopmentCycle [14:40] kid3-qt shows no kde BG running when it does so that is fine. [14:42] The main date to look out for is when feature freeze happens. We can add and change stuff until then, without problems. After feature freeze, we need permission each time we do an upload. [14:42] * OvenWerks has a list of apps to exclude from media playback and add to audio production... [14:42] *in the menu stub [14:42] Ah, yes. The menu might need to be refreshed a bit [14:43] There are some audio tools that might be interesting... like the jaaa and japa tools, also a tunner (guitar or otherwise) would be nice [14:44] sakrecoer: Oh, if you want too keep up with changes for the blueprints, make sure to subscribe to the ones you care about [14:44] about the schedule: weeks are counted from 1 week of the year right? :D [14:44] No, from when development begins [14:44] oh... [14:44] Roughtly the last week of April, or the first week of May for this cycle [14:44] so... how do i read the dates?... [14:44] There's no actual schedule yet [14:45] But, consider May feature definition period [14:45] ok :) [14:46] so when you write: "Oh, if you want too keep up with changes for the blueprints, make sure to subscribe to the ones you care about" thats in launchpad right? [14:46] OvenWerks: I haven't kept up to date at all with changes in the repo [14:46] sakrecoer: Yes. There's a blueprint for each package basically. That's how I'm organizing them [14:47] ok :) thanks! [14:47] ubuntustudio-meta is the source code package for all of our meta packages [14:47] That's always a good place to start [14:47] I am only mentioning tools I happen to use. The two ja* tools are useful for live sound [14:47] OvenWerks: Would be good for us to go though the whole categories of audio and graphics, etc, to find out what else is out there [14:48] I made a script that created a list of stuff at one time [14:48] There could be other ways [14:49] I think a submenu for audio utilities may be in order. [14:49] Sure [14:50] We group some of the high use ones in the main audio menu, but for less used ones it would make sense. [14:51] We could have a submenu for jack [14:51] If I can get -controls to control jack and PA, then that would be the beginners first choice [14:51] what would go in there... or what would not go in there :) [14:51] aha... now i think i see how tightly interconnected the workflow concept is to the menu system... [14:52] qjackctl at least, and any other jack control app [14:52] But, audio utilities might be better, yes [14:52] Yes I was thinking -controls would replace things like qjackctl... or could even lanch it if needed [14:52] *launch [14:52] I'm thinking -controls launches at boot. User makes some first time settings, like does the user want jack always running, etc [14:53] It also has a system check script which runs at each login, and informs if something is not working right [14:53] I still need to finish the simple version, which only handles RT privilege, and SRU it to trusty [14:53] Way behing in the schedule [14:54] qjackctl seems to be more robust as a connections manager than patchage, though I like the patchage layout [14:54] Yep. Patchage only starts jackd as well [14:54] At least last time I looked [14:54] I have had patchage crash on me to many times to use it all the time. [14:55] i always confuse patchage and gladish... [14:55] sakrecoer: The menu became a direct reflection on the workflow idea [14:55] personaly i use the patchbay in qjackctl ... [14:55] I never really liked adding audacity to the video workflow, or strictly speaking - to the video meta [14:56] There are a couple of other packages that are duplicated in the metas [14:56] sakrecoer: that is why you will find some apps in the menu twice.. in different workflows [14:56] yeah... that "audio" enrty in video is very confusing.. [14:57] Well, actually. Having it in the meta is not bad. But, you would always look for audio applications in the audio category [14:57] So, let me change my words there :) [14:57] Our ubiquity plugin is not that smart though. It doesn't handle duplicate packages well [14:58] I have no problem with taking the audio sub out of video. [14:58] Would be better to just let the user choose between the metas, not the individual packages [14:58] ..or smartify the plugin [14:59] If an application can be used for both graphics and video, I can understand it being in both those categories [14:59] zequence: last time I installed it seemed to handle individual packages even across two metas. disabling a package in one meta automatically removed it from the other as well. [14:59] But, audacity is not used for video, so I agree on removing it too [15:00] OvenWerks: Really? I have not changed the code. I need to check that behaviour again [15:00] Not good if it removes a package from the wrong meta [15:00] i would really like to push for a "visual" node in the blueprint.. this node would then connect to photo, graphics, video and publishing... [15:01] by node, i think i mean meta... or maybe its meta-meta? [15:01] sakrecoer: The blueprints are organized after the actual meta packages [15:01] I would think if a user chooses an app they don't want in any workflow they just don't want it. but if unchoosing a whole meta removes things from other metas that is no good. I did not check that. [15:01] What you are suggesting is we have a visual meta that includes all the graphic metas [15:02] That does not make sense [15:02] yes, ubless it would imply intolerable amounts of headbending and work... [15:02] sakrecoer: I still think there's a difference in how we organize the audio menu to how you think of suborganizing the visual workflow [15:02] unless even [15:02] IN the audio menu, we suborganize by tool type - not workflow [15:03] This is not true for the categories of video, photography and pulbishing [15:03] thats what i owld like to see in the "visual" menu.. [15:03] While, I agree that graphics is a broad field [15:03] Ah, right [15:03] tool types would be: 2d, 3d, video and publishing. [15:03] So, you think we should organize our metas by the tool types too, in sub metas? [15:04] i feel to unexperienced with the thinking thinkering to claim we should... but i'm playing with the idea, yes [15:04] I also think we should not forget photography, even if it has great similarities to 2D in general [15:04] The problem with sub menus, is that not all DEs handle them very well. [15:04] true... i was seeing photography in 2d... [15:06] The clasic menu in gnome3 is a good example. [15:06] (or bad) [15:06] i see... [15:07] OvenWerks: Perhaps we can join -installer with -menu, making it an app that you can use for browsing, starting, and installing [15:07] falktx has something similar, I think [15:08] Unless we assume that desktops today are desined for casual use and development work (which all our workflows are) should have a real menu and desin a menu for the systray/indicator. [15:08] If we have our own app, we don't depend only on the menu [15:08] :) [15:08] You had the idea of a systray meny app. That's worth exploring too, I suppose [15:09] Unity is in a way that. It has categories, installed an non-installed. Even internet results [15:09] I would have no problem with incorporating the installer. [15:10] I think the icon needs to indicate if the application is already installed or not. [15:10] (or the text) [15:10] A menu in the systray should probably not show non-installed apps, but a browser could [15:10] Unity separates installed an non-installed in two different fields [15:11] It could... [15:11] They could show up as "Install some app" and then just "some app" when local [15:12] Problem is if you have too many uninstalled application in the menu, just taking up space [15:12] I have seen things ship with an "install firefox" menu item for example [15:12] Well right now we have one menu item for install more * applications [15:13] We could leave it at that [15:13] software center? [15:13] Yes, and I could even go with a single "Find more apps" button [15:13] no sw center [15:13] sakrecoer: we have our own (not very good yet) installer [15:13] right, i read that but forgot... [15:14] sakrecoer: we want to take the ubiquity plugin and use that instead. [15:14] I need to go away for a bit, but I'll read the backlog [15:14] is that what you are discussing? as in not discussing the menu? [15:14] Alternatives to the menu [15:14] and in addition to [15:15] i see ) sorry.. [15:15] The two things are intwined [15:15] yes.. makes sense. [15:16] One of the things we want to do... is give DE choice or make adding Studio to an already installed *buntu a possibility. [15:17] So both our menu and installer needs to work with any DE [15:17] in many ways i think the current options to install aditional sw is very good.. but of course if it has to be integrated in many different DE it becomes more complicated... [15:17] Or maybe less [15:18] to put it another way it may have to be less complicated to work at all [15:18] yes, that is the optimal situation.. [15:19] i mean... i see what you mean... :) [15:19] I would really like to have the menu applet from xfce as an indicator/systray applet [15:20] how is that different from now? [15:20] sorry if that is a dumb question... i guess i'm not sure about what an indicator/systray is as opposed to how the menu is now... [15:20] in xfce it would not be different, but in unity, there would be an indicator that was a menu [15:20] ok... [15:21] unity does not have a menu per say, in a systray menu I would not put the whole menu, just our workflows. [15:22] The menu has two functions: [15:23] 1) to start applications. unity does not need us to duplicate that. If the user knows what they want unity already works [15:23] 2) to show users what they have to work with. That is apps they don't know how to find in unity or new apps they have never tried before. [15:24] An experienced user might never use a systray menu and might disable it all together [15:24] Thats ok. [15:25] i see... but wouldnt' we need to do that for all DE available to ubuntu then? [15:25] systray/indicator covers them all [15:25] this asked, i agree that adding only the workflows to the existing menu is optimal.. [15:26] perfect! [15:26] systray is the older spec and indicator is newer [15:26] ok... i'm too unaware of these two elements to have a relevant opinion i guess :) [15:26] There is code that looks to see if an indicator area is available and use it or systray if not. [15:27] indicators normally fit in with the desktop theming better [15:27] unity does not come with a systray [15:27] xfce has both [15:28] which DE uses systray only? [15:28] lxde might [15:28] fvwm and others like that [15:29] ok [15:29] In some ways I would like an indicator that has a systray in it. There are some nice audio app systrays [15:30] I normally run qjackctl to start and stay in the systray for example. [15:30] i'm getting closer to a vision of what you are aiming for :) [15:31] dang it.. i have to get AFK.... [15:32] I have to go to... gotta play in an hour or so, [15:32] thank you for your patience and thought food! [15:32] rock on1 [15:32] :) [15:32] any help would be wonderful! [15:32] count me in! [15:32] :) [15:32] sakrecoer: Yes, thanks for joining us. [15:33] cya soon! === sakrecoer is now known as sakrecoer_idle