[14:24] <len-dt> micahg, good morning, just an update on packages that require release or other work.
[14:24] <micahg> len-dt: are you giving me a list or do you want to know if I've uploaded any :)
[14:24] <len-dt> The seeds/metas need to be looked at, ubuntustudio-default-settings
[14:25] <len-dt> list
[14:25] <len-dt> ubuntustudio-look
[14:26] <len-dt> and I have tested ubuntustudio-default-settings.precice... what next?
[14:27] <len-dt> micahg, I can check if you have uploaded any as you change them to released.
[14:27] <micahg> len-dt: the bugs that are being SRUd need the appropriate paperwork, then I can upload
[14:29] <len-dt> micahg, I have not been able to find where xchat gets it's server list from.
[14:30] <len-dt> I am not sure what to do with that.
[14:31] <len-dt> For adding ubuntustudio to firefox, there is a place to do that.
[15:01] <micahg> yeah, not sure about xchat, will have to dig a little
[15:01] <len-dt> I am looking at the server list in the source code...
[15:08] <len-dt> micahg, The ubuntu version of the xchat source code patches things to put debian and freenode at the top and connect to the #ubuntu forum by default.
[15:09] <len-dt> maintaining a ubuntustudio version of xchat sounds like a lot more work than a /etc/skel/ file.
[15:11] <len-dt> It is possible to start xchat to connect to a specific forum (a *.desktop file could be created) but then the users config would not work.
[15:12] <micahg> len-dt: perhaps an alternative might be useful, it depends on how that patch works (which I haven't looked at yet)
[15:13] <micahg> OTOH, maybe we can add a hook in the main xchat package for derivatives to override the default entry
[15:13] <len-dt> micahg, Ok, beyond my skills though.
[15:14] <len-dt> I could probably change the patch for a US version, but not add a hook.
[15:15] <len-dt> I agree that an alt to allow each flavour to add their channel would make sense though.
[15:53] <scott-work> ailo: ping
[15:57] <micahg> len-dt: I'd rather have something like /etc/xchat.d/ubuntustudio
[15:57] <micahg> but that probably needs some packaging work
[16:01] <scott-work> ooh, ooh, is this about making #ubuntustudio a default channel in xchat?
[16:01] <micahg> yeah
[16:01] <scott-work> yay!
[16:07] <len-dt> scott-work, don't get too excited yet.
[16:08] <scott-work> hehe, at least it is progressing though :)
[16:08] <scott-work> len-dt: you have a minute to talk about the menu stuff?  ailo, can catch up when he is online
[16:08] <len-dt> ok
[16:09] <len-dt> there seems to be a feeling that menus are not the place to define workflows.
[16:09] <len-dt> That items should be in a submenu that matches the definition of the app
[16:11] <len-dt> For example, some one making a music cd would expect to make the music in audio, but look for a program to make the case cover in graphics.
[16:11] <len-dt> scott-work, ^^
[16:13] <scott-work> let's say i'm a video guy, new to linux, but i understand the work flow of making a video...trying to move away from mac or windows
[16:14] <scott-work> in a practical sense, i know nothing about linux audio. don't know the applications names and don't know what they do. hell, i don't even know jack about jack :P
[16:14] <scott-work> i try using ubuntu studio to edit video
[16:15] <scott-work> i see "openshot" there are start importing, cutting, moving video around but i need to add some sound effects and voice overs but need to edit the audio
[16:15] <scott-work> s/are/and
[16:15] <scott-work> if audacity is *not* in the video menu, i would most likely go to the 'audio' menu and see all the applications
[16:16] <scott-work> i don't know what audacity is, not jack, nor ardour...it's all confusing to me
[16:16] <scott-work> if audacity *is* in the video menu, i have an immediate and visual clue, especially with the menu tool tip, that ubuntu studio has been designed for me to use audacity to edit the audio for my video
[16:16] <scott-work> ..
[16:17] <scott-work> i'll mention two more things about the menu
[16:17] <len-dt> That is what a) docs are for b) a workflow application.
[16:17] <scott-work> len-dt: we dont' have a work flow application yet
[16:17] <scott-work> and even if we did, we have to confirm that it actually works and helps users
[16:17] <len-dt> We will keep getting bug reports to answer 
[16:17] <scott-work> before making a decision to remove things from the menu
[16:18] <scott-work> len-dt: i am only aware of a single bug so far, has there been others?
[16:18] <scott-work> bug# 984970
[16:18] <scott-work> bug #984970
[16:18] <len-dt> A fair amount of talk on IRC and the list.
[16:18] <scott-work> and that one was by ttoine
[16:19] <scott-work> len-dt:  has this honestly confused people? (other than *head scratch* "hey, why is that there?")
[16:19] <len-dt> I won't change it. I can't really say as to confusion. I am only relaying what I have heard.
[16:21] <len-dt> scott-work, moving on, what other menu related things did you have
[16:22] <scott-work> len-dt: i'm sorry if i am being aggressive to you, i did not intend to be so, especially to you
[16:22] <scott-work> len-dt: you are quite a valuable people to this project and represent a very fair and conservative approach to it as well
[16:22] <scott-work> len-dt: i certainly would not want to alienate you in any way
[16:23] <len-dt> scott-work, not a problem. I am still just learning.
[16:23] <scott-work> s/people/person
[16:23] <scott-work> to be honest, i can't remember both things i was going to add, but i do remember one
[16:23] <scott-work> ah, maybe i do
[16:27] <scott-work> 1. i am confused and surprised by the strident opposition to this - i can only speculate that it is because it doesn't follow convention and that offends some (i understand because there are other areas where i am the same way)
[16:28] <scott-work> 2. i also think that breaking with convention or tradition can be a good thing (i certainly believe it is a helpful thing to our users) that can help innovation
[16:29] <scott-work> oh, and a #3
[16:29] <scott-work> 3. audacity should still be in the 'audio' menu and the only ones to see it also in the 'video' menu would be those who use the 'video' menu, therefore i'm not sure this is "hurting" anything
[16:30] <scott-work> ..
[16:30] <len-dt> OK
[16:30] <scott-work> i would really like to see a method for creating, editing, and setting a "mode"
[16:31] <scott-work> adjust the menus, the screen layout, the number of monitors, even docks with applications
[16:31] <len-dt> Mode or workflow?
[16:31] <scott-work> mode based on work flows
[16:31] <scott-work> view the "mode" as a system setting
[16:31] <ailo> scott-work: I have no objection against breaking convention. But I think I've made my point already. No one is expecting an audio application in a video menu, no matter what. Even with documentation on the US website saying this is how we do our menus, most people would not have read it. 
[16:31] <len-dt> I have been using mode to mean something different.
[16:32] <scott-work> s/as a system setting/as system settings
[16:32] <ailo> scott-work: I know your aim is for it to be intuitive, but I feel it is the opposite
[16:32] <len-dt> That is more of a system setting than I had envisioned.
[16:32] <scott-work> ailo: but what is the detraction if it _is_ there?  (other than it just shouldn't be there and people will not expect it)
[16:33] <ailo> scott-work: If we put all applications that could suit a certaing workflow in other menus, it will be flooded with double, or triple entries
[16:33] <len-dt> scott-work, I am not sure it is possible to change panel settings on the fly like that with any of the existing panels.
[16:34] <ailo> scott-work: It not economic, and it's confusing
[16:35] <ailo> scott-work: If you'd like to start designing a workflow application instead, never mind the coding, I think what you'd start with is a tag based application database
[16:35] <ailo> scott-work: Each application could suit many workflows, and could have many tags
[16:36] <ailo> scott-work: This is partly what the menu is aiming to do now, except it's only been begun
[16:36] <scott-work> ailo: i think the "double, or triple entries" argument may be a straw man (i'm trying to say this nicely but i don't know how to say it without it sounding ugly and i apologize for that)
[16:36] <ailo> scott-work: I can't find one single argument for having double entries in the menu, tbh
[16:37] <ailo> Since no one is aware of the workflow design, except the designer himself
[16:37] <scott-work> what i meant, is that i do not think there will be too many double entries
[16:39] <ailo> scott-work: It would make much more sense to create documentation where you list suitable applications for each workflow. 
[16:40] <scott-work> ailo: i would presume that you do not think having audacity in the video menu as a visual, immediate cue for those unfamiliar with linux applications is not a good argument?
[16:40] <scott-work> (for someone who know video editing work flow already but unfimiliar wiht linux)
[16:41] <ailo> scott-work: I think a new user would immediately assume Audacity is a video application, and after starting it, wonder where the video is
[16:41] <ailo> Since again, the new user has no idea about the workflow design
[16:41] <ailo> And even if he did, he'd not know which is a video application and an audio application
[16:42] <ailo> == confusing
[16:43] <ailo> scott-work: Why not just create a workflow starter? It wouldn't be too much work, even for an average coder. Just a window with starters
[16:43] <ailo> scott-work: I could help with that before 13.04
[16:44] <ailo> I mean, a workflow app, with starters
[16:44] <ailo> Or the panel..
[16:45] <len-dt> ailo, the panel doesn't really lend itself to that use as is.
[16:46] <ailo> A workflow application with starters would have the main categories for the worflows, and subcategories for whatever you want: recording, editing, processing, etc
[16:47] <ailo> A much more throrough and complete categorization. Would be much more clearer for the user
[16:48] <ailo> len-dt: Would you know how to create a menu in the panel, like the main menu?
[16:50] <ailo> Actually, it would need to work just like the main menu, except only have multimedia apps, and in much more thorough categories. 
[16:50] <len-dt> Not like the main menu
[16:53] <ailo> I haven't looked at how that could be done in python, which I prefer myself (since I don't really do C a lot).
[16:53] <ailo> But shouldn't be too hard to find out
[16:54] <ailo> The program mathces against a list of multimedia apps and sees if those are installed. If yes, then it loads them to the menu
[16:55] <len-dt> I don't know if you remember, but I originally had something like this: http://www.ovenwerks.net/UStudiodocs/workflow.html
[16:56] <len-dt> It is effectively it's own panel.
[16:57] <len-dt> As you can see at the bottom it is easy enough to make it work as a menu.
[16:57] <len-dt> The menu is not hard coded BTW, it is created fresh at each startup.
[16:58] <len-dt> It could read the config files fresh each time selected though... just take longer.
[16:58] <ailo> len-dt: How much longer?
[16:59] <len-dt> But then, the main menu takes longer to display if you change the menu file.
[16:59] <len-dt> I don't know as I haven't tried it.
[17:00] <len-dt> It uses desktop files. The config file is a workflow(s) with a list of desktop files inside.
[17:00] <len-dt> An application can be added without a desktop file as well.
[17:03] <len-dt> The application can be purposely added without a desktop file for the purpose of changing the icon, tooltip or command line.
[17:06] <ailo> len-dt: scott-work: Here's an example of a possible design for a menu. Main categories are workflows. Sub categories are tasks. http://paste.ubuntu.com/1119803/
[17:06] <ailo> If we were to use workflow design on the main menu, we need to include the task category. If we do that, then it would make sense
[17:08] <ailo> So, for the workflow category "audio" we'd have different tasks, such as "Recording/Mixing" and "Editing"
[17:09] <ailo> "Mastering", "midi-tools", "plugin-hosts", "instruments", etc..
[17:09] <ailo> Not really tasks, but task based
[17:11] <ailo> len-dt: scott-work: Coming back to the main menu, I'd be curious to see if this would work. But, again, first step would be documentation. What tasks are there for these different workflows?
[17:12] <ailo> And applications that don't fit a task, or are hard to categorize, just leave them in the main workflow menu
[17:12] <ailo> scott-work: With a subcategory inside video, that said audio-editing, I could see the point in putting Audacity there
[17:12] <len-dt> ailo, you mean do this in the mani menu?
[17:13] <ailo> len-dt: With clear subcategories, maybe it would work?
[17:13] <len-dt> Or do you mean have a second workflow menu?
[17:13] <ailo> len-dt: If not in the main menu, than definately as a workflow menu
[17:15] <len-dt> I will see what I can do.... I know that ubuntu's old gnome menu had three menus, main, places and system
[17:17] <scott-work> sorry, was caught up at work, reading backscroll now
[17:18] <scott-work> i believe the menu is not only created fresh at each startup but also when an application in installed or the text file edited manually
[17:19] <ailo> scott-work: He was explaining how the menu worked on the panel that he maid, if I understood correctly
[17:19] <ailo> made*
[17:19] <scott-work> oh, sorry
[17:19] <len-dt> scott-work, yes. I have edited things a lot.
[17:20] <scott-work> ailo: are you suggesting something like a "workflow wizard"?
[17:21] <len-dt> The applications menu takes longer to load after a file change. So it must first check to see if the file has a new write time.
[17:22] <scott-work> i don't think that is a substantial time though, is it?
[17:22] <scott-work> ..
[17:22] <ailo> scott-work: I haven't suggested it now. 1. I say not to the current form of the menu. 2. I talked about creating an application starter application 3. We talked about using the panel for that. 4. We talked about creating a menu in the panel for that 5. I realized, with the addition of clear taks based subcategories in the menu, it might be clear enough when used in the main menu
[17:23] <ailo> scott-work: The key IMO is task based sub-categorization. 
[17:23] <scott-work> maybe we should ask ourselves other questions...
[17:23] <ailo> ?
[17:23] <scott-work> i.e. how can we most effectively engage the user with work flows?
[17:24] <scott-work> and i suppose what the purpose of us "engaging the user" with them
[17:24] <scott-work> and who exactly are we engaging?
[17:25] <ailo> scott-work: Do you see the point in having task based sub categories for workflows?
[17:25] <ailo> Does anyone?
[17:26] <ailo> I'm going to get something to eat. bbl
[17:31] <len-dt> I am out for a bit too. Will look at the possibility of a second menu in a panel.
[17:41] <ailo> scott-work: It's been pretty clear for me from the start. Handling workflows in an abstraction from the interface which is the current desktop tool base. i.e. it's a layer above the tools that exist. How to create a guide? 1. Documentation 2. Creating an application that dynamically leads the user to a specified task in a workflow
[17:45] <ailo> schould be, .."is an abstraction of/from the interface". In any case, a layer above the tools
[17:54] <scott-work> sorry, was pulled away by work again...reading
[18:01] <scott-work> sorry, pulled away again, and now meeting time, be back in hour, but will think about your comments ailo "abstraction above tools"
[18:03] <ailo> scott-work: I think the key here is (and I did realize this some months earlier too, just haven't been thinking about it), is task based subcategories for the main workflow categories.
[18:04] <ailo> scott-work: Cause, when you are looking to do a task, you look for applications that match the task you want to perform
[18:06] <ailo> scott-work: "Audio", "Video", etc, aren't telling you much. But task based categoried can be quite precise
[18:09] <ailo> IMO, "audio", "video" etc, aren't workflows at all, until there is a follow up
[18:21] <ailo> as in audio/recording, audio/editing, video/recording, video/editing
[18:22] <ailo> It's not perfectly easy to create task based categories, I think. To create a complete and practical list for each workflow main category qould require some thought
[18:23] <ailo> I might have less problems doing it for "Audio", but "Video" would be a little harder, without research
[18:26] <len-dt> ailo, what I am hearing is we need to document workflows before we can set up the tools.
[18:31] <ailo> len-dt: That has always been my opinion. And I would gladly help with that, but not at the moment, as we have more basic tasks to complete first
[18:31] <ailo> Also, when it comes to documentation
[18:32] <len-dt> ailo, I think so.
[18:32] <len-dt> I know I can't do it as I don't have enough experience even in audio, my strongest case.
[18:34] <ailo> scott-work might argue that the workflows should be designed with a novice user in mind, but IMO, there is no difference.
[18:34] <ailo> Just the choice of applications, perhaps
[18:35] <len-dt> ailo, novice in mind, but designed by someone who has learned already from their own novice mistakes.
[18:35] <ailo> A novice video person would probably use OpenShot, to make youtube videos, while a pro would use something like kdenlive
[18:35] <ailo> But the task is still the same
[18:37] <ailo> len-dt: I do agree that it is important to have experience in pro/semi pro production. And the more fields, the better
[18:37] <ailo> Someone who only does one type of art, and one type of style, and maybe only one application has a small window to the world of workflows
[18:38] <len-dt> Ok ailo just looking at some xfce4-panel docs. It looks like there is a way to have a second (different) menu.
[18:39] <len-dt>  I will try making one :-)
[18:39] <ailo> cool
[18:46] <len-dt> ailo, I would consider it the best thing if the first item on a workflow menu was a help button pointing to a document that explains the concept of workflows
[18:47] <len-dt> ailo, each submenu should have it's own help button explaining the workflow(s) that submenu was meant to handle.
[18:48] <len-dt> ailo, this will require making *.desktop files and maybe directory files as well.
[18:48] <ailo> len-dt: Good idea. I'm just looking at the docs about workflows that already exist
[18:48] <ailo> There is a bit of work done, by a lot of people in fact
[18:49] <ailo> But it's loose and unstructured
[18:50] <len-dt> ailo, as a mock up I will use desktop files we already have. I will not fill all the categories, perhpas just video or graphics because there are less app to choose from...
[18:50] <ailo> len-dt: If you look at the links for "audio", "video", etc, you'll find different workflow cases here https://wiki.ubuntu.com/UbuntuStudio/Workflows
[18:55] <len-dt> yes I have seen those. I can get the apps from there..
[18:56] <ailo> len-dt: I see those as sketches, but since they are based on experience, it makes them good for reference.
[18:57] <len-dt> Ok, My first one will be very basic anyway. Just a test of concept.
[18:57] <ailo> len-dt: I'm sketching out something on what I was talking about in the wiki now. Workflow based menu
[18:58] <len-dt> Ok.
[19:00] <scott-work> damn webchat keeps hanging up and dropping me
[19:00] <scott-work> ailo: i agree with your categorization comment
[19:02] <scott-work> ailo: i'm not sure i would argue that work flows should be derived with a new user in mind, i think the result would be the same for any user
[19:03] <scott-work> but i would argue about how you document it or engage the user would vary on the user's experience
[19:04] <scott-work> but we should keep in mind, we can always document infinite number of work flows, but the number we "support" by shipping applications should be limited, perhaps as few as one work flow per task
[19:05] <len-dt> scott-work, I think we need to document the ones we ship.
[19:05] <len-dt> I don't know that documenting other workflows will help
[19:06] <len-dt> Saying there are other way to do the same job is ok. Suggesting other apps to replace an app in our current toolchain may be ok too.
[19:07] <len-dt> scott-work, I don't know if you caught it or not, but I have figured out how to add a workflow menu to one of our tool bars (top or bottom)
[19:13] <len-dt> scott-work, ailo, currently mine resides in my bottom/side pannel
[19:14] <scott-work> len-dt: oooh, i didn't see that, do you have a link? is this like your previous work with the panels?
[19:15] <len-dt> No this is like a second applications menu.
[19:15] <scott-work> len-dt: by "document the ones we ship" do you mean the information in wiki.ubuntu.com or do you mean help.ubuntu.com / ubuntustudio.org?
[19:15] <scott-work> i ask because i view those two repositories of information as having two disticntly different purposes
[19:16] <len-dt> I would like to ship a document that can be accessed at the top of each workflow menu on the ISO
[19:16] <scott-work> and also i don't mind having a "community" supported section of work flows that are "unsupported" (i.e. not shipped) that can help provide information
[19:16] <scott-work> len-dt: good idea
[19:16] <scott-work> i like that quite a bit actually
[19:17] <scott-work> if we did ship a "work flow application", it would be nice if a particular key combintation would launch it...perhaps ala the HUD or dash with vanilla ubuntu
[19:17] <len-dt> I am running out of time today, but I will do a short web page with some pictures later.
[19:18] <len-dt> workflow application is down the road yet.
[19:19] <scott-work> after reading hte mailing list a bit: i quit using firefox some months ago, i now use chrome/chromium
[19:19] <len-dt> Should we make it default?
[19:19] <micahg> I wouldn't suggest that until it's properly cared for (unless you all are volunteering for that)
[19:20] <len-dt> micahg, That bad ? ok scrap that.
[19:22] <ailo> scott-work: len-dt: the audio menu is in fact quite close to what I sugges, when it comes to workflow categorization, and is the best defined.
[19:23] <ailo> We should just put more energy on defining good subcategories for all the workflows
[19:24] <len-dt> ailo, you realize some sub menus would have only one app?
[19:25] <len-dt> Can we put text in separators?
[19:26] <len-dt> Gotta go... Bye
[19:29] <scott-work> len-dt: i was wondering that also about separators, i'm not sure actually....no, wait, yes we can, i know that, we have it in the main menu (which i gratuitously stole from xubuntu)
[19:30] <scott-work> ailo: to be clear: are you suggesting that the 'video' menu actually show no applications in it, but rather have sub-menu(s) based on work flows?
[19:31] <scott-work> (this would be similar to what the 'audio' menu is doing with the sub-menus, but rather than base on sub-types of audio applications or genres, we would base the video sub-menus on pure work flows?)
[19:38] <ailo> scott-work: I think to justify having an application in many "main" categories, you need to specify a clear sub-category for the application starter, so that it is clear what it is used for
[19:38] <ailo> scott-work: So, yes
[19:39] <ailo> len-dt: Depends on how many submenus are created, and how many applications are installed
[19:40] <ailo> len-dt: scott-work: the amount of submenus needs to be designed also from a practical point of view, cause we would easily put 3-4 categories in the audio menu, where perhaps half of the applications would be in all of them
[19:40] <ailo> s/would/could
[19:41] <scott-work> granted there does not need to be unity between the audio and other categories, i.e. we don't have to follow the exact rules between them
[19:47] <ailo> scott-work: len-dt: So, this is nothing new. It's the same thing as we have now, pretty much. I added something, and probably missed something. https://wiki.ubuntu.com/UbuntuStudio/WorkflowMenu
[19:47] <ailo> I would prefer to fill out all of those categories, discuss problems, make changes, and then implement them to the menu
[19:49] <ailo> scott-work: Applications that do not fall under a specific sub-category, we just put in the main category, as before.
[19:55] <ailo> scott-work: len-dt: I don't have the time to continue working on that. I would estimate a couple of days to get a good first version
[19:55] <ailo> For all the workflows, that is
[19:56] <ailo> And add all possible applications, even those that aren't available in the repo
[19:56] <ailo> bb tomorrow. Time to sleep here
[20:01] <ailo> scott-work: Ah yeah. I was thinking about having a "difficulty level". Something you could have in a workflow application, but in a menu? If used in a menu, I would suggest adding (basic) to some applications, but it's pretty hard to find simple apps for much of the workflows, probably
[20:02] <ailo> I mean, some applications will still require you to learn 10-100 different things
[20:02] <ailo> Even if you only use them for very simple things
[20:03] <ailo> Openshot, while not useless, is basic
[20:03] <ailo> I don't know if any of the DAW's are