len-dt | ailo, how goes? I don't suppose you have seen the logs from earlier? | 03:30 |
---|---|---|
ailo | len-dt: For some reason my server, which hosts this irssi client sometimes falls asleep | 04:24 |
ailo | I'll check.. | 04:24 |
ailo | What Scott is talking about concerning jack is pretty much what I'm aiming for with -controls | 04:27 |
ailo | Simple jack control from an applet (start|stop), and "connections" which opens patchage | 04:28 |
ailo | Patchage needs to be opened in no-start-jack-automatically mode | 04:28 |
ailo | Also, one might consider readapting patchage to be as plugin, so that only some of the code would need to be custom | 04:29 |
ailo | About the workflow panel.. | 04:29 |
ailo | len-dt: I still think the only good answer is a dedicated software for it, like your panel | 04:30 |
ailo | I'm on a usb install of lubuntu precise at the moment. One thing that seems to be a lot different is cpu freq | 04:47 |
ailo | It likes to stay on lowest, and tries to quite agressively with the ondemand option | 04:47 |
ailo | Both cores are fluctiating even when I have a few flash videos playing. They hardly stay at full juice, and one of them is often down at 800MHz. Seems quite effective | 04:49 |
len-dt | ailo, patchage... does it handle alsa midi connections as well? or does a2j have to run? | 05:14 |
len-dt | I agree about the workflow panel for two reasons: one the panels we have are not made for switching on the go, so it would be a hack. The panels we do have _are_ made to be changed by the user... and those changes stay even after a distro upgrade. Our own app can have system workflows we can change from release to release... or add with a meta. The user could add their own too. | 05:18 |
len-dt | ailo, I found even with qtractor, 4 synths and hydrogen, I could run at forced 800MHz on my netbook. (single core) | 05:20 |
len-dt | I didn't try two flash videos at a time, but one was not even 50% cpu. | 05:21 |
ailo | len-dt: Patchage is both midi and audio in the same view | 06:14 |
ailo | Haven't yet explored it much more. It autostarts jack if you don't give it a flag | 06:14 |
ailo | I like it since it's mostly just a jack connections app | 06:15 |
ailo | Would like to just keep that part | 06:15 |
len-dt | ailo, I meant does patchage do both jack mid and alsa midi. | 06:26 |
ailo | len-dt: Yep | 07:06 |
ailo | len-dt: It can also change frame/period while running | 07:06 |
ailo | It can't save connections, but I would assume it is, or will be ladish compatible | 07:07 |
ailo | It should be able to save, but it's disfunctional on this install anyway | 07:08 |
knome | us website now has a favicon | 10:20 |
smartboyhw | astraljava: You here? | 10:39 |
smartboyhw | News: The ISO QA Tracker declared the ISO images of the 12.04.1 builds READY! | 11:33 |
smartboyhw | strange: no one goes to test the amd64 images...But 2 or 3 tested i386...Real weird! | 11:34 |
smartboyhw | I mean no one except me for amd64 | 11:39 |
len-dt | smartboyhw, That is an interesting fact. So there are actually still lots of people using i386 machines. | 13:37 |
smartboyhw | len-dt: Uh oh | 13:37 |
len-dt | This is interesting because it is getting hard to buy 32 but machines besides atom based. | 13:38 |
smartboyhw | len-dt: That's true | 13:39 |
smartboyhw | o/ scott-worj | 13:39 |
scott-work | thanks knome for fixing the favicon! | 13:39 |
smartboyhw | scott-work: The ISO images is declared ready | 13:39 |
scott-work | hi smartboyhw | 13:39 |
scott-work | good :) | 13:39 |
len-dt | hi scott-work we were just noticing that there are more tests on 32nit machines | 13:40 |
len-dt | *bit | 13:40 |
smartboyhw | Only me on amd64 | 13:40 |
len-dt | I was thinking I was the only odd one with 32 bit HW, but I guess there is still a lot out there tha is 32 bit | 13:41 |
len-dt | scott-work, both ailo and I feel it would be better (maybe easier as well) to make our own panel/workflow app, than to muck with the panel(s) we already have | 13:44 |
* len-dt has played around with other panels besides just xfce | 13:44 | |
smartboyhw | len-dt: +1 | 13:44 |
scott-work | len-dt: hmmmm, i don't know about a new test, nothing in -release channel mentions it from what i can see (although i only logged on) | 13:46 |
smartboyhw | New test? | 13:46 |
len-dt | There is no new test | 13:47 |
scott-work | sorry, did i misread your comment? | 13:47 |
smartboyhw | scott-work: He meant to implement another panel besides xfce | 13:47 |
len-dt | There has been talk that some flavours will only come with 64bit kernel | 13:47 |
scott-work | oh, i see what you are saying (sorry, i got phone call and people at my desk while reading) | 13:47 |
smartboyhw | len-dt: Really? Not us, I think | 13:48 |
scott-work | len-dt: i'm pretty agnostic about implementation, but i ask one big thing | 13:48 |
scott-work | len-dt: i would ask that we clearly define what we are trying to do and make sure it makes sense before we go willy-nilly into coding | 13:48 |
len-dt | server will come with either a 64b server k or 32b generic | 13:48 |
smartboyhw | Well, server is better in 64-bit. | 13:49 |
len-dt | Only if you have the HW to support it | 13:49 |
scott-work | i have serious concerns about how some are trying to revive -controls without being able to say what its purpose would be | 13:49 |
len-dt | a lot of small servers are whatever HW is left over.... 32 bit | 13:49 |
scott-work | i feel very, very strongly that we need to have a *very* clearly defined goal for our app(s) before we code and implement it | 13:50 |
smartboyhw | scott-work: Agree. +1 | 13:50 |
len-dt | That is a good thought. | 13:50 |
scott-work | i have equally large concerns that we might be trying to fit too much into -controls (or possibly any single app) | 13:50 |
smartboyhw | :) | 13:51 |
len-dt | scott-work, I would not worry about that unless it is something we expect to leave running | 13:51 |
scott-work | i don't think -controls should be for 1) setting user in audio group, 2) getting a kernel, 3)starting/setting jack, 4) adjusting workflows, 5) installing new work flows, etc | 13:51 |
len-dt | 1) is ok IMO, setting jack could be ok, but not starting. getting a kernel? I think we ship what we ship. | 13:53 |
smartboyhw | I agree setting Jack. People having problems in Ubuntu Forums about jack mainly | 13:54 |
len-dt | adjusting workflows to me would include installing... sort of. Most WFs should be installed by a meta that includes the SW needed | 13:55 |
=== cyphermox_ is now known as cyphermox | ||
len-dt | starting WFs should be a separate (small quick) app | 13:55 |
ailo | -controls is all about settings. If you can't make settings with it, what is it good for? | 13:56 |
len-dt | ailo, I agree | 13:56 |
smartboyhw | o/ ailo. I agree | 13:56 |
len-dt | We have different words, controls/config but they mean the same thing | 13:57 |
ailo | There are two things I have in mind for -controls. 1. it should be simple and help the user easily configure the system on any ubuntu derived distro (not only Ubuntu Studio). 2. it doesn't matter if it has more than it needs, as we need feedback from users to find out what features are needed and which are not. | 13:57 |
ailo | I'm making it plugin based | 13:57 |
smartboyhw | ailo: Complete agree from me. It works. | 13:57 |
len-dt | Even us as devs need to have it so we can look at it | 13:58 |
ailo | So, it's not one huge application | 13:58 |
len-dt | ailo, by plugin you mean that the plugin is called just as needed? | 13:58 |
ailo | len-dt: I mean, I'm splitting it up in many packages. | 13:59 |
ailo | There's a main package that will create an applet in the panel | 13:59 |
ailo | Each plugin will populate the applet, or add to windows that are opened from the applet | 13:59 |
ailo | It could also be put in a worflow panel | 14:00 |
ailo | I mean, instead of the main panel | 14:00 |
ailo | scott-work: I really don't understand your standpoint in this. If you want something done, you have to do it. | 14:02 |
smartboyhw | ailo: +1 | 14:02 |
ailo | You can't plan things in detail before hand | 14:02 |
ailo | scott-work: But, if you feel you'd want to, I won't stop you | 14:02 |
ailo | I'm thinking about creating a one for all audio control interface. Simple as can be. If someone needs something more advanced, the other applications will still be available. | 14:04 |
ailo | As a part of the applet | 14:04 |
ailo | Also, we've been talking about modes | 14:04 |
ailo | I'd like to add that too | 14:04 |
smartboyhw | ailo: Are you sure you can deal with so many things at once? | 14:05 |
ailo | I'm also making two versions of the whole thing. I'm pushing a more general version into Debian, calling it something like "pro-audio-controls" | 14:08 |
ailo | So, even if for some reason it is not approved, it will be available in Ubuntu anyway | 14:09 |
ailo | I mean, approved for Ubuntu Studiop | 14:09 |
smartboyhw | Wow wow wow, ailo, I am seriously wondering that your brain is full of code now:) | 14:09 |
ailo | smartboyhw: It's not that much code really. But of course, it takes some time to write it | 14:10 |
smartboyhw | LOL | 14:10 |
ailo | scott-work: I think one big problem in how you think about Ubuntu Studio is you are not worrying about any other debian/ubuntu based distro in the equation. To me, the whole purpose of Ubuntu Studio is to improve multimedia on Ubuntu based distros generally, and serve as an example of a well configured version of it | 14:14 |
smartboyhw | ailo: YEAH!@ | 14:14 |
smartboyhw | That's why I like Ubuntu Studio. | 14:15 |
smartboyhw | Strange: So is it ailo and len-dt and me vs. scott-work now? | 14:15 |
ailo | It would be d slightly ifferent, if Ubuntu Studio was not an official derivative. | 14:15 |
ailo | smartboyhw: I think you might be in your own team ;) | 14:16 |
smartboyhw | Yep, but since now it is:) | 14:16 |
smartboyhw | ailo: What da? | 14:16 |
smartboyhw | ailo: What do you mean?:( | 14:16 |
ailo | scott-work: If you want to realize your ideas about workflows, I say, go the full length. Stopp messing with XFCE menus and panels, to try to find a shortcut. | 14:18 |
ailo | And, as always, if you want to collaborate on something, document first | 14:18 |
ailo | Otherwise, it doesn't exist | 14:19 |
smartboyhw | ! | 14:19 |
len-dt | ailo, I think because we are doing something new we need to have code we can look at and try out. | 14:20 |
smartboyhw | len-dt: Yeah. I'm willing to try it out | 14:20 |
scott-work | ailo: my point is pretty simple, i believe - i don't want -controls to be a "catch all" for any functionality that we might want to incorporate | 14:21 |
len-dt | So I need to do my own PPA so I can have other people try out what I have | 14:21 |
scott-work | ailo: i'm not planning everything out, i think i'm doing some common sense activities, thinking about what we are trying to accomplish before we start | 14:21 |
holstein | scott-work: i saw your ping yesterday | 14:21 |
scott-work | ailo: i think it would be beneficial to have a clear set of goals (issues we want to address and possibly conditions of success to gauge if we have address the issue) before we get it all done | 14:22 |
holstein | scott-work: i think i would need to see the xsession idea to really wrap my brain around it | 14:22 |
len-dt | holstein, that is the thing. we need something to look at and try. | 14:23 |
scott-work | holstein: len-dt explained to me that not using xsessions would be a better approach | 14:23 |
smartboyhw | Wow, that's almost the most active discussion since I joined here:) | 14:23 |
smartboyhw | I want to try new things:) That's why I like testing | 14:23 |
ailo | scott-work: As len-dt said, as long as there isn't anything to testrun, or even documentation that can give a picture of what something does, it's hard to have an opinion about it | 14:25 |
ailo | scott-work: I'm making the application nevertheless, and I believe my approach is as optimal as can be from all angles | 14:25 |
ailo | scott-work: Plugin based means it can be whatever you want | 14:26 |
smartboyhw | :) | 14:26 |
len-dt | scott-work, if I had to logout/in every time I changed functions... I would not use that functionallity | 14:26 |
holstein | http://iso.qa.ubuntu.com/qatracker/milestones/230/builds is this the current 12.04.1 page? | 14:27 |
smartboyhw | Yep | 14:27 |
smartboyhw | 2 people for i386 (one is len-dt), one person for amd64 (me) | 14:27 |
len-dt | change of workflow should be able to happen with one click | 14:27 |
holstein | smartboyhw: not where im looking.. says we are done, and xubuntu has a few cases left | 14:28 |
smartboyhw | True, I'm testing Xubuntu alternate amd64 now:) | 14:28 |
holstein | smartboyhw: you just asked the xubuntu-dev channel for help testing the iso's? | 14:30 |
smartboyhw | holstein: Good work | 14:31 |
smartboyhw | True | 14:31 |
smartboyhw | I did, no one is testing Alternate for them | 14:31 |
holstein | oh i see... to see if anyone is one it already... i usually mark myself early... just like when im working on the newsletter | 14:31 |
smartboyhw | Good work means the e-mail you just sent | 14:31 |
holstein | i put my name on the articles im about to start working on so we dont duplicate efforts | 14:31 |
smartboyhw | I'm thinking that my CPU is going to explode soon due to too much usage on testing OSes. | 14:32 |
holstein | hehe... work it! | 14:32 |
len-dt | scott-work, ailo changing workflow: 1) close or at least alert the user of any non-workflow apps. | 14:36 |
len-dt | 2) start or ask user if they want to start base processes such as jack/a2j | 14:36 |
len-dt | 3) if it is a session based workflow, start a session (may require user input to decide which session/project)) | 14:37 |
len-dt | That is maybe a bit simplified... | 14:38 |
smartboyhw | len-dt: Good job:) | 14:39 |
ailo | smartboyhw: I wasn't able to answer your PM's as this nick isn't properly logged in, just so you know | 15:08 |
smartboyhw | Oh | 15:08 |
ailo | smartboyhw: Don't worry too much about what I say though. | 15:08 |
smartboyhw | LOL | 15:08 |
scott-work | len-dt: just for the record, i was thinking about using changing xsessions when changing modes, rather than just work flows (which is why i was querying you about how often you thought about changing modes vs. work flows yesterday) | 15:18 |
scott-work | but of course, it appears that changing xsessions is certainly not an optimal solution :P | 15:18 |
len-dt | scott-work, that is why we need to know _what_ has to change. | 15:20 |
scott-work | agreed | 15:20 |
len-dt | Changing menus is probably not that hard | 15:20 |
len-dt | changing what is running system wise is not that hard either... but starts to get distro specific real quick. This takes away from Ubuntu's "give back to the community" ideals | 15:22 |
smartboyhw | :) | 15:22 |
len-dt | I think both ailo and I want something that can be used in *ix systems in general not just US. | 15:22 |
scott-work | len-dt: to be honest, if an stand-alone app is used for work flows then we probably don't need to worry about adjusting menus, doe we? | 15:23 |
len-dt | I don't know, scott-work, the only way to find out is to build it and try it on real projects | 15:24 |
smartboyhw | len-dt: Let's see:) | 15:24 |
scott-work | i'm sure i don't explain myself very well, but i'll try | 15:25 |
scott-work | i mentioned before about defining what the problems are that we are addressing, and conditions for successfully addressing the problem. | 15:26 |
scott-work | this is implementation agnostic. both in sense of what method is used to implement and the actual action | 15:26 |
scott-work | for example, work flows are not immediately obvious to user could be the problem | 15:27 |
scott-work | without talking about panels/apps (implementation) or changing modes/menus (actions), we can still define the problem and... | 15:28 |
scott-work | "having a visual element on the desktop (one that would draw user's attention and invite investigation" could define the success condition | 15:29 |
len-dt | The reason I don't know if having a menu change would help is that I was thinking that a workflow pannel would have the main apps on it in the order of use, but extra tools and utilities may be better not cluttering that up and so a mini menu might be usefule | 15:30 |
scott-work | this is how i like to approach problems, in an somewhat abstract way | 15:30 |
scott-work | len-dt: right! | 15:30 |
scott-work | this is why i was asking people to reimagine the desktop, without constraints, yesterday to envision a perfect future state of what we would like to use | 15:30 |
len-dt | Some of us are unable to think that way and need a picture at least, but prefereably a working app to try | 15:30 |
scott-work | len-dt: i understand, ailo helped me quite a bit to see some of my deficiencies | 15:31 |
len-dt | It is easy to come up with ideas, but there are tons of apps that on first look are really, really useful, but once installed _never_ get used. | 15:31 |
scott-work | agreed, totally | 15:32 |
scott-work | which is why i wanted to make sure that we are actually solving a problem and that people will want to use our solution | 15:32 |
scott-work | oaky, i need to finish talking to people before a meeting but i'll be back in a few hours and hopefully continue this conversation | 15:32 |
len-dt | scott-work, when you get back... xfce panel is happy to get it's menu via a link | 15:37 |
len-dt | Rather than put this in the bottom/extra panel (which some people just throw away anyway) I would put it right next to the tray. Call it a context menu. With just applications related to the workflow. | 15:40 |
len-dt | It would seem like a tray icon. | 15:40 |
len-dt | An example of where this would be useful (ok might be) is for things like mixers. I wouldn't want a mixer starter in a workflow panel because there are so many for different audio cards. | 15:46 |
* scott-work is about to go downstairs for meeting | 15:47 | |
scott-work | but i wanted to put this out there... | 15:48 |
ailo | len-dt: It would be cool if the proper mixer would appear only if its' device was loaded and present | 15:48 |
scott-work | seeing jackpanel application made me reimagine the desktop for audio and think, "what _should_ be an applet on the panel for default? what do we use ALL the time for audio?" | 15:48 |
scott-work | i think jack controls would be helpful for one | 15:49 |
scott-work | ailo: very true | 15:49 |
scott-work | should the work flows "menu" or "icon" what whatever be an applet in the top panel? | 15:49 |
smartboyhw | Well, bye bye now | 15:50 |
scott-work | by smartboyhw | 15:50 |
scott-work | i am also heading downstairs for the meeting now | 15:50 |
len-dt | so having a menu to take care of it might be handy... or the user might just reach for the main menu they are used to. | 15:51 |
len-dt | ailo, ya, it would be nice. What are the downsides of that? | 15:52 |
ailo | len-dt: The only problem is making sure a database of devices for the functionality is up to date | 15:52 |
ailo | One would need to list them manually | 15:53 |
len-dt | What if a USB device is plugged in. the mixer would have to change/get added on the fly | 15:53 |
ailo | There are services for that | 15:53 |
ailo | Just like how nautilus updates its' contents, if you create a file using a terminal | 15:54 |
ailo | Well, maybe not "just like" | 15:54 |
ailo | I don't know how exactly, but surely it can be done | 15:55 |
ailo | That's probably not the first thing you'd want to develop though | 15:55 |
len-dt | Ya, it should be able to be done. how often do we want to scan for new devices so we can add new devices? | 15:56 |
ailo | Even though, I think it's important to keep things like that in mind, cause that will enable you to strategically design the software to be able to use such functionality later, if added | 15:56 |
ailo | len-dt: Any usb devices that have dedicated mixers, btw? | 15:58 |
ailo | len-dt: One way to do it is to search for devices each time you open the menu | 15:59 |
len-dt | ailo, I am not sure. Many of them have no mixer... levels are controlled on the box. | 15:59 |
ailo | That way, you don't need any particular service. The only downside may be that opening the menu is slower | 16:00 |
ailo | len-dt: But, I'm imagining dedicated software now, not XFCE menus. Not sure what you are thinking of right now | 16:00 |
len-dt | I was thinking some of each :) a panel/dock that has the major apps for the function and an xfce menu for utilities. | 16:02 |
len-dt | However, having the workflow start the applications needed is another way to go. | 16:02 |
len-dt | that would be what session managers are for.... but for graphics and publishing too | 16:03 |
ailo | A few years back, I imagined a panel much like the Unity panel, but unlike unity, one that was totally dynamic. In the upper corner, you'd have a global control/button. Say, you point your mouse there, and the whole panel becomes global. As soon as you take it away, the panel becomes customized for what application is up. You push it, you get a global menu system. The custom mode could system controls in the lower corner, that are | 16:07 |
len-dt | Though maybe for graphics or video or whatever things are done more in a sequential manor. In audio (in Linux) it is normal to use a number of apps at the same time | 16:08 |
len-dt | ailo, that was what I tried to do with my workflow panel | 16:08 |
ailo | As for the exact content in the middle, it's hard to imagine off the bat. It needs to be worked out, by getting down and dirty with the code | 16:09 |
len-dt | I didn't think of using hovering to bring up the global menu though :) | 16:10 |
ailo | Me neither, in the past | 16:10 |
ailo | That is something you get from gnome-shell | 16:10 |
len-dt | or unity for that matter | 16:10 |
ailo | Something to condider is that some applications may fit many workflows | 16:12 |
len-dt | OK, why would that be odd? | 16:13 |
ailo | If you make the panel show only a certain workflow, it gets confused if you want to use an application for a different workflow | 16:14 |
ailo | I really don't have a clear idea about the details. I do think the user should be able to customize stuff | 16:15 |
ailo | Let's say, the workflow content is just a set of launchers. And we have our standard workflows with applications we have chosen for them. A user might want to create their own custom workflows, adding whatever applications they want | 16:16 |
ailo | Didn't you do something like that? adding starters from a list in a file? | 16:17 |
ailo | Aside from launchers, one would want to have some system controls. Jack control for audio (and perhaps choosable also for video) | 16:18 |
ailo | I'd put those at the bottom | 16:18 |
ailo | The launchers should be docks for the applications too, or whatever you call it. | 16:19 |
ailo | After an application is launched, pushing the icon should only bring that app up front. Not start a new one, unless doing right-click, open new | 16:19 |
ailo | Just like the mac/gnome-shell/unity panels | 16:20 |
ailo | Perhaps a tool button at the bottom. A generic toolbox for workflows, where you can add controls or starters however you want. Mix anything with anything | 16:21 |
ailo | Finally, the workflow is actually more like a profile | 16:21 |
ailo | Another solution with hovering, is to expand the panel to show all the workflows(profiles) next to each other. Important to have the possibility to delete some, since probably no one will use them all | 16:25 |
ailo | I could imagine using the panel not just for multimedia, but for everything | 16:26 |
ailo | A wizard of some kind would be good to have. One that creates a template for you. | 16:27 |
ailo | How would it work, if you'd combine menus with started applications, in the same panel? | 16:28 |
ailo | The docks and menus would be like the submenus | 16:28 |
ailo | like the submenus in the main menu | 16:29 |
ailo | len-dt: I do think what you have is a good foundation, which allows for these kind of ideas. | 16:30 |
ailo | So, all that is missing is just starting to develop some of those | 16:30 |
ailo | I mean, anyones ideas.. | 16:30 |
ailo | I'm sleeping early today. bb refreshed, tomorrow | 16:31 |
len-dt | Gn then ailo . | 16:33 |
scott-work | len-dt: a single application for work flows could also control a panel (perhaps on the side looking like a "dock"), and you could set the "mode" and a different panel would be loaded | 16:48 |
scott-work | which would only show the pertinent work flows | 16:48 |
scott-work | damn, it's very weird reading ailo's comments, it's like he's been reading my not published blog post :P | 16:50 |
scott-work | here is what i had been working on: http://paste.ubuntu.com/1162983/ | 16:55 |
scott-work | wow, i wrote that on my laptop using libre office write during a vacation trip, pasted that into blogger, and now pasted it into pastebin....that did wonders for the formatting :P | 16:59 |
len-dt | scott-work, I think each US meta should come with its own workflow(s) as needed. As such each workflow configuration needs to be it's own file | 17:06 |
len-dt | The files a meta comes with would be in /usr/share/something | 17:07 |
len-dt | each user would have a workflow directory in .config/something/ | 17:07 |
len-dt | this directory would have both workflow files but also a config file. System workflows that are not used or replaced with a user custom one would be recorded here so that system WF would not be displayed. | 17:10 |
len-dt | That way if a new meta is downloaded it's workflows would show up by default | 17:11 |
scott-work | oh, interesting idea...you are saying include the work flow configuration along with the meta, i was viewing it as another package that would have the configuration file in it...hmmmm | 17:11 |
len-dt | scott-work, what I am saying by talking "nuts and bolts" is that the current panel gets disconnected at install time | 17:12 |
scott-work | i was worried about this due to the ubiquity plugin and if a meta was not installed, your method may solve this problem | 17:12 |
len-dt | That is the first time a user logs in the current panel gets set in stone and no change to the system template will show up. | 17:12 |
scott-work | using the work flow app as a frame work (as ailo said) and view things as plugins (as ailo said) for which the meta's provide the "plugin", this might work very nicely indeed | 17:13 |
len-dt | We don;t want our workflows to be unchangable, we want both user cusomisation as well as the system to be able to add things. | 17:14 |
len-dt | I think a configuration utility should allow reset. If a user customizes a workflow they should be able to go back to stock if they want. | 17:16 |
len-dt | So there are two kinds of cutom workflows, those started from scratch as new WFs and those that modify an exsiting WF | 17:17 |
len-dt | there could be a third kind that uses an existing WF as a starting template but does not replace it. | 17:17 |
scott-work | oooogh, really good idea len-dt ! a "reset button" is a must | 17:17 |
scott-work | this is the kind of abstract thinking i like! :P | 17:18 |
stochastic | hi all | 17:18 |
scott-work | hi stochastic :) | 17:18 |
len-dt | hello | 17:18 |
stochastic | the release notes for 12.04.1 seem pointless - it's just a bug fix release | 17:28 |
stochastic | I can't even find any Ubuntu 12.04.1 release notes | 17:28 |
* stochastic isn't sure if we should even publish them | 17:29 | |
knome | stochastic, they are integrated to the 12.04 notes | 17:29 |
knome | xubuntu didn't change anything | 17:30 |
stochastic | I don't think we need to publish anything then. | 17:37 |
knome | tell that to skaet @ #ubuntu-release and she will stop worrying :) | 17:37 |
stochastic | knome should we publish the previous release notes on the website (those that haven't reached EOL)? I notice only 12.04 is published, but people might be interested in seeing the earlier release notes | 17:40 |
stochastic | they're written as drafts currently behind the scenes | 17:40 |
knome | umm | 17:40 |
knome | if you think that helps, then go for it | 17:40 |
knome | we did that | 17:40 |
knome | (xubuntu) | 17:40 |
stochastic | okay I think it'd be good to do. It gives new users proof that this isn't our first release too. | 17:41 |
* stochastic will take care of that | 17:41 | |
stochastic | scott-work, I was thinking about how we've been pairing down our meta packages to only the key tools and it gave me an idea | 17:43 |
stochastic | I personally like to have lots of options for my productions but understand this isn't optimal for our ISO purposes. Maybe we should look into creating a audio-extras meta that would include all the bells and whistles. Similarly with the other metas | 17:50 |
stochastic | ^^ or if scott-work is busy others can share their opinions | 17:53 |
stochastic | those metas would obviously not ship with our ISO, they'd just be useful for people wanting all options for sequencers or notation programs or wave editors or etc... | 17:54 |
scott-work | stochastic: i believe that is similar to what len-dt has mentioned before :) | 17:57 |
scott-work | stochastic: are you basing this on work flows, perhaps? ones that are created but we don't necessarily want to ship be default? | 17:57 |
scott-work | i think it sounds like a great idea | 17:58 |
stochastic | scott-work, no, not on workflows but rather on the plethora of tools in the repos that a new user might want to explore | 17:58 |
stochastic | I think it would be useful for the extras package to stay away from the workflows idea simply because that process is a great tool for limiting the applications to just the best or primary ones but these packages should contain everything else | 17:59 |
scott-work | stochastic: what would be the criteria for selecting the applications? | 18:00 |
stochastic | I would say any package that could be seen as multimedia production related and functional | 18:01 |
scott-work | that could be a *very* large package, no? | 18:01 |
stochastic | well we'd segment them into audio/video/graphics/photography/etc... extras | 18:02 |
stochastic | but yes they'd be very bloated | 18:02 |
stochastic | the impetus behind this would be that some users can find workflows that they prefer that us all-knowing devs haven't even conceived of yet (or haven't determined fit into our meta structures) | 18:05 |
len-dt | stochastic, what I have done instead of that (and it can be changed) is to add an menu item that opens software center with a list of things the user may want to install. | 18:06 |
stochastic | I guess that's a cleaner way of doing it len-dt | 18:07 |
len-dt | If we can ever get our -default-setting released, I would like other people to look at it | 18:07 |
stochastic | I'd love to see it | 18:07 |
stochastic | :) | 18:07 |
stochastic | all in due time I assume | 18:07 |
stochastic | is FF today? | 18:08 |
len-dt | I don't know. But this has been commited for over a month now I think. | 18:08 |
stochastic | okay | 18:08 |
stochastic | I'm pretty sure FF and 12.04.1 happened on the same day irc | 18:09 |
len-dt | micahg, said he was doing it... but I haven't see him for a bit | 18:10 |
* stochastic won't hold his breath but will expect it done soonish | 18:11 | |
stochastic | :) | 18:11 |
micahg | len-dt: yeah, I'm on vacation, but unlike my other vacations, I've been busy with family :0 | 23:29 |
micahg | but will try to get to it | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!