[01:45] Duke was added by: Duke [06:55] * OvenWerks is not happy with the new icon theme... [06:56] I find it hard to find tool bar stuff like the save icon is harder for me to pick out. [06:58] The meni icons are generally ok, but some of the toolbar stuff is monochrome and so less easy to use. [06:58] *menu [15:38] OvenWerks: I'll go ahead and revert it. I found that to be difficult, too. Seems the dark color they used too closely matches. [16:08] OvenWerks: I might try the deepin icon theme next and see what you think. [16:08] Eickmeyer: it is certainly the way things are going, the newer theme _does_ match FF and glade which use their own icons [16:09] Eickmeyer: I don't think we need a US icon theme, only to use _a_ default theme [16:10] Well, the US icon theme has some extra icons for apps that don't contain their own for whatever reason. [16:10] It also carries our distributor-logo icon. [16:10] If we need to add Icons for our own or missing we should just add them to hi-colour [16:11] That's not a bad idea. I don't know why that wasn't done before. [16:11] In other words no a theme per se but rather extra icons [16:11] Right. [16:11] That way the user is not locked into the US theme they can choose any theme and be happy [16:12] It might take a bit to make that change, but I'm glad to take it on. I just don't know if it will make it in time for 19.04. [16:12] By the way our extra menu directory icons seem to be there already [16:12] That's part of -menu, as far as I can tell. [16:13] So maybe move any actual icons in the icon theme there... might only be two or three [16:14] Well, I can easily move those to hi-color and change the package name to ubuntustudio-extra-icons, with ubuntustudio-icon-theme becoming a transitional dummy package. [16:14] Eickmeyer: I would just add them to menu [16:15] It seems odd to have a package for three icons [16:15] most of the ones that seem to be missing are in mixers [16:16] I'll see what I can do. That might be a solution. Either way, -icon-theme would need to become a transitional dummy package anyhow. [16:17] meh, deepin wouldn't work for a default anyhow, I guess we'll stick with elementary-xfce-dark. [16:17] AH, we seem to be missing the alsa icon... [16:17] That is what I went back to :) [16:18] The default panel icon, our logo, also seems to be in -icon-theme. [16:18] Did we drop hexter? [16:18] that would be safer in hicolour [16:18] I don't know. It doesn't seem to be there... [16:19] it says it is installed here [16:20] Strange. I search for it in Whisker and it's not ther.e [16:21] I am showing it installed too. [16:21] Ah, my mistake, it is really a plugin and relies on a dssi wraper to run standalone [16:21] Ah.... you had me panicking. [16:22] but it doesn't show up in Carla :P [16:25] It seems broken [16:27] Carla does use the right path. [16:27] when I try xdg-open hexter I get Gtk-Message: 08:24:49.811: GtkDialog mapped without a transient parent. This is discouraged. [16:28] And I get a dialog that says: Unable to detect the URI-scheme of hexter [16:31] Hmm xdg-open does that for anything maybe xdg-open is broken? [16:32] or maybe I am using it wrong? [16:32] I am using it wrong [16:35] OK hexter does work. If I go to /usr/share/applications/ and double click on hexter.desktop it does start [16:35] (So I wonder why Carla doesn't see the plugin) [16:39] Huh, Carla doesn't show _any_ of the five dssi synths at all [16:39] Bug in Carla I guess [16:40] Eickmeyer: ^^ [16:43] qtractor shows it fine [16:48] OvenWerks: I think that might be a bug that was fixed upstream, I'll check. [16:48] (sorry 4 synths) [16:49] We don't export LV2PATH, LADSPAPATH DSSIPATH [16:54] The upstream package of Ardour should probably put /usr/lib/ardour5/LV2 [16:54] contents in /usr/lib/LV2 [16:54] (or provide links) [16:55] Looks like they are fluidsynth based, and, iirc, Carla doesn't support fluidsynth. [16:55] there is only one fluidsynth the others are not [16:55] Hmmm.... [16:55] Carla will load fluid synth [16:56] Here's the log on that one: carla-discovery::info::skipping fluidsynth based plugin - /usr/lib/dssi/fluidsynth-dssi.so [16:58] Ya but if I add /usr/lib/ardour5/LV2 to the LV2 path, Carla happily loads a-fluidsynth [16:59] There is a calf version too. I think that rather than fluidsynth based he means dssi based... in which case he should remove the dssi selection [17:01] OvenWerks: It looks like it found issues with all 4 of those plugins: https://paste.ubuntu.com/p/QsZ4Fq4pHK/ [17:02] He has a whole slew of DSSI plugins in the KXStudio repo that work. [17:02] I can file this as a bug report to see what he says. [17:02] All of those plugins are not and have not been actively developed for some time. [17:03] Hmmmm... [17:03] I think xsynth was sort fo abandoned and then whysynth is a fork of xsynth and then also abandoned. [17:04] fluidsynth should be used from either calf or the a-series of LV2 plugins anyway [17:05] Agreed. Should we not even worry about it then? [17:06] However, qsynth probably uses the fluid synth dssi plugin... [17:07] I will look abit fartherxsynth/whysynth may be a part of the dssi lib package (for free) so it would be hard to remove them without breaking qsynth [17:08] Okay. I won't take action for now then. [17:08] If they work... we can add icons for the three of them (fluidsynth already has a gui that works) [17:09] I don't know why hexter is not shown now... -menu bug? [17:11] No -menu bug, it doesn't even have a .desktop file in /usr/share/applications. [17:11] Either an upstream bug or deliberately removed. [17:11] Ok may I installed locally [17:13] Xsynth has no GUI but does run. Whysynth will not start at all [17:15] Actually it does have a GUI but I don't seem to have it :) [17:46] Eickmeyer: ok, Studio does ship fluidsynth-dssi, hexter, whysynth and xsynth-dssi [17:47] Yeah, but it appears as though hexter doesn't contain a .desktop file which would put an icon in the menu [17:48] under installed files I find: /usr/share/applications/hexter.desktop [17:48] Unless that has been dropped since 18.04 [17:49] I see hexter.desktop there, but it's not making an icon anywhere. [17:49] That was weird, I didn't see it there before. [17:49] That was I thought bug in the menu [17:50] I looked in menu and it doesn't seem like it should be missing. Care to take a look? [17:50] It does show no icon. I thought that was one of the icons we added though [17:52] seems I haven't looked that in a while.. I still have the bzr version :) [18:00] Hexter is definitely in -icon-theme, but I don't know if it's being called correctly. Might just have to move it to hicolor. [18:07] OvenWerks: -icon-theme is now reverted to basing on elementary-xfce-dark. [18:15] I can not see why hexter does not show up... at least the menu file looks correct. I guess I should check my system file maybe it was fixed. [18:17] nope my system file is fine. [18:18] OvenWerks: I found in the .desktop file that hexter is looking for an icon at /usr/share/pixmaps/hexter.xpm that doesn't exist. [18:19] That might be the reason. [18:21] Additionally, hdspmixer is looking for the alsa-tools icon, not its own icon in either hicolor or -icon-theme. [18:26] but those ones show up yet hexter doesn't [18:27] I tried using a totally different file renamed to hexter.desktop with the internal name changed to hexter. still no show. [18:30] problem is that we override the thing with: /usr/share/ubuntustudio/applications/hexter.desktop... which is borked. [18:30] which package installes that? [18:30] Eickmeyer: ^^ [18:30] Looking... [18:33] It looks like it was thought that the two would add together... but they don't and it can't find the icon anyway. [18:34] that should just be removed. probably in one of the -settings packages. or maybe icons [18:34] It's in -default-settings. [18:36] There's actually quite a few files in that directory. [18:36] Including hdspmixer.desktop [18:37] Yes, I think that needs to be looked at. [18:37] I think the idea was that the installed desktop files did not have an icon and we would supply one. [18:37] I don't think it's doing what the intention was supposed to be. [18:38] we should leave hexter in there, but copy the stock one and just replace the icon with a generic one. [18:38] no. the whole desktop file has to be rewritten [18:40] the xterm should be left out. As things progress the xfce term may go the route of the gnome term which has privilage problems [18:41] The package in ubuntustudio-defaulkt-settings [18:41] Okay, I moved the hexter.desktop from /usr/share/applications into that directory and changed its icon to the default hexter one from hicolor. [18:42] I removed the debian-xterm.desktop file. [18:43] Is there a reason why we're doing a nodisplay=true for xfce4-terminal.desktop? [18:43] OvenWerks ^ [18:44] Same question for Thunar, Thunar settings, etc. [18:45] I think because we make them both available as "default" terminal and file browser [18:46] So they are already covered by another desktop file [18:47] That's fair. [18:48] I think we may like to remove the nodisplay for debian-xterm though [18:49] maybe wait to see if the same problem that is hurting the gnome terminal shows up [18:49] It may never and xfce terminal is quite good. [18:53] I removed the nodisplay. [18:53] Really, the entire desktop file since that was the only entry. [18:54] Committed, pushed, and building. [18:55] Also fixed the hdspmixer file since it was also incomplete. [18:58] The reality is that any of the audio correction desktop files should be moved to the menu package. Also any icons that go with them [18:58] I agree with that. Also, if this works, I don't see any reason why the icons can't be removed from -icon-theme. [19:00] Any of these that are xfce specific should be in a ubuntustudio-xfce-settings package. Unless default=xfce in which case we need a more generic one [19:00] but I think you already did that [19:00] Yes. [19:00] Honestly, it wouldn't matter unless they had those tools installed, which they likely wouldn't without Xfce. [19:01] Re: Thunar, mostly. [19:01] does the package depend on thunar? [19:02] No. [19:03] Well, -default-settings does, but not -menu. [19:04] To be safe, we can keep the Xfce-specific ones in -default-settings and move the generic ones to -menu. [19:05] OvenWerks: ^ [19:06] I think that makes sense [19:07] So the things I think you are doing: move the icons from icon theme to menu. Move the desktop files to menu [19:09] so now that the ubuntustudio icon theme is going to go we also need to have the xfce settings point directly to the default icon theme we will use :) [19:10] * OvenWerks feels he should not play with these packages if you are already :) [19:10] Yeah, I'm messing with 'em. [19:11] -icon-theme will become a transitional dummy package as soon as I'm done. [19:18] As you are going for upload rights, the more activity that shows up the better. [19:20] * OvenWerks puts on Ardour dev hat for a while... [20:24] OvenWerks: The fix to the icons in /usr/share/ubuntustudio has worked. Hexter now shows. [21:06] OvenWerks: Unfortunately, it looks like the distributor-logo icon needs to remain in /usr/share/icons/ubuntustudio, otherwise it would cause potential package conflicts if installed in hicolor. Ubuntu keeps its in the Humanity theme and Xubuntu keeps theirs in the Xubuntu theme (which, like ours, follows elementary-xfce-dark). No flavor installs their icon theme to hicolor. [21:06] Rather, no flavor installs their distributor-logo to hicolor. [21:33] So, pretty much the only reason to have ubuntustudio-icon-theme is for that distributor-logo icon at this point. [21:39] Eickmeyer: -default-settings then, it seems silly to have a package for one file... [21:39] It's for multiple sizes of the same icon. [21:39] also -*-settings I guess [21:39] But, yeah, that does seem like a good place for it. [21:41] Can we put it in /usr/share/ubuntustudio/icone/hi-colour/* ? [21:41] I just pushed a bunch of changes now. [21:42] In order for the distributor-logo to be ours (as opposed to Ubuntu, Xubuntu, or even Debian) ubuntustudio-icon-theme has to be the default. Otherwise it'll default to the wrong logo. [21:42] I think we have it in there as a different name for the menu etc. [21:43] So it is still accessable even if the user chooses a different icon theme after install [21:43] We do, but when applications look distributor-logo, they'll find whatever is the default for that icon theme. [21:44] It has less to do with the menu and more to do with applications themselves. [21:44] * OvenWerks thinks a link sounds ideal for this [21:46] Rather, the applications look for the distributor logo based on whatever the active icon theme is. [21:47] So, ubuntustudio inherits elementary-xfce in herits hicolor. [21:47] * Eickmeyer can't type worth a darn now. [21:48] Likewise, xubuntu inherits elementary-xfce inherits hicolor. [21:48] Or, Yaru inherits Humanity inherits hicolor. [21:49] Right so the icon called distributor-logo should be a link to /etc/alternatives [21:49] Right so the icon called distributor-logo should be a link to /etc/alternatives/link_to_our_logo [21:49] just like /usr/bin/editor [21:50] /etc/alternatives is full of links for the same purpose (our plymouth is inthere for example) [21:52] The problem is that this would have to be started upstream, not just Studio. [21:52] we could put a bug in though [21:52] though I am not sure which package to put it in :) [21:52] You're right, but yeah, not sure either. [21:53] That's a can of worms, for sure. [21:53] Ideally, that's the right way to do distributor-logo, and using an icon theme is a hack. Unfortunately, it's the prescident. [21:54] Do we have to use elementary xfce dark? is elementary dark missing something big? [21:55] I'm not seeing anything weird, except it uses the older icons. [21:56] They're a bit dated. [21:57] Everything is "dated"... [21:58] I understand. Where I'm at is that, as an "artistic" project, we need to keep up with the trends in desktop aesthetics. [22:00] I understand, I also understand that this is one of those areas where I can't really see the difference. So I don't tend to complain so long as everything works when I change to something I can use daily. [22:01] Totally, I get that. [22:01] All I can do is give opinion and reasons for them. I understand that for a lot of things I am (probably by design) out of touch. [22:04] I have an idea. How married to the Numix Blue theme are we? [22:04] I don't use it... [22:05] Maybe I do [22:06] Okay. What if we switched to Arc Darker (light theme with dark borders) by default with Papirus icons? That way we would still have our dark titlebar & menus & panel, but maintain our light theme, and the standard Papirus icons use a light color for their simple icons. [22:06] Numix style, elementtary dark, theme Mohei [22:06] (is what I use) [22:09] Install arc-theme, switch to the theme with Papirus icons (should have remained installed from before) and tell me what you think. [22:10] Right now, we're maintaining the Numix Blue theme, and that's probably not in our best interest. [22:10] But I somehow have an "orange" title bar for active window decoration [22:11] That's because you're using the standard "Numix" theme as opposed to our Numix Blue. [22:11] Ok, ya I did that on purpose [22:12] Plasma allows you to edit the style [22:12] You're in Plasma right now? I'm in Xfce. XD [22:13] No I am in xfce [22:13] I just remembered being able to edit the style somewhere and realized it was plasma [22:13] Oh, okay. [22:14] Which arc? [22:14] (dark or darker) [22:15] Darker, and use ePapirus. I found a flaw with using Papirus-dark. [22:17] start ardour... [22:18] Done, Ardour is running with an empty session. [22:18] Does it have great white bars? can you read the menu text at the top? [22:18] Yes, no problem with the menu at the top. [22:19] Huh that was Ardour 6, 5.12 is ok... let me restart 6 [22:20] (Photo, 1280x720) https://i.imgur.com/Mg35Zm7.jpg [22:20] ardour 6 is fine when restarted [22:21] do you have geany? [22:21] I've noticed that a lot of apps have to be restarted if you change the theme. [22:21] What's geany? [22:21] development tool [22:21] Ah, the IDE. I do most of my editing in Mousepad & Git Cola. [22:22] When in Xfce, that is. [22:23] I just installed Geany. [22:23] Is there something I should see? [22:23] http://i.imgur.com/3Mx7K2H.png [22:23] look at the toolbar [22:24] Yes, I see the same here. [22:24] I can hardly see any of the toolbar icons [22:25] Try Papirus Dark for the icons. [22:25] Maybe in part because the main window is so bright [22:25] It might be that. [22:25] Changing to Papirus Dark prevents the icons from showing up in the menus. I think that's why they made ePapirus to be an in-between. [22:26] None of the papirus icons seem to be any different for those icons in use [22:27] BTW elementary xubuntu dark claims to be broken. [22:28] Just says the icon cache needs to be updated. [22:28] Opps... I was looking at the screen shot [22:30] papirus dark is better for geany yes. [22:30] but if it messes other things up... [22:30] I removed icons from menus and buttons, seems to do the trick. [22:32] Dark is darker than darker... I must think wrong [22:32] That's always confused me too. [22:32] Not the only theme that does that. [22:33] darker is darker than normal, dark is dark. [22:34] That must be the logic. [22:37] Anyway, choose whatever is best for the flavour, I will probably go back to Moheli becasue it allows the title bar to cleary show the active window rather than just changing the shade of the text. [22:40] Gotcha. [22:41] Part of the idea of these things is to be able to choose what the user wants and I like what I had. I may even use the elementary dark :) [22:44] I do use the numix style, but don't let that stop you from removing numix, I can work with something else [22:47] OvenWerks: We don't have to remove Numix, it's in the repos. It's "Numix Blue" that we maintain ourselves. [22:48] Ya, don't do that we have too much already to do [22:49] Exactly, that was my thought behind removing it. Takes the burden away. [22:50] It's a subpackage of -look. [22:58] OvenWerks: I think I figured it out. Papirus icons on the Adapta-Eta GTK theme. [22:58] Back later, gotta pick up my son from schoool. [23:47] I'm back.