Re: Validity of bugs whose solution involves adding an option somewhere
Hi, I have thought about this a lot too, as a developer. It is hard to make an overall judgment that is true in all cases. Sometimes an option really is needed, and trying to "workflow" around it just leads to frustration. Take for example, the fact that you have to log out to get to a shutdown button on Windows 8 -- this leads to huge frustration for users because they don't have the option to shutdown from the desktop. Sure, *there exists a workflow* for them to shutdown, but it is more complicated than necessary. On the free desktop, the two extremes of option implementation that I see are GNOME 3.x versus KDE 3.x (or, arguably, recent KDE 4.x too). On the one extreme, anything that could be seen as an option is avoided. On the other extreme, and especially with KDE 3.x, almost every application has a toolstrip (or two toolstrips, or three) along the top of the window with various actions and options. One perspective that I have held recently is that the needs of power users and software developers are very different from the average user. Thus, it stands to reason that a desktop that is useful to developers is going to look very different from a desktop that is useful to end-users. This might explain why my assessment of all the recent desktops -- from GNOME 3.x, to Unity, to KDE 4.x, to Windows 8, has been pretty much the exact opposite of the typical non-tech-savvy user. "If they love it, I hate it" -- and vice versa. However, my perception is that we *needn't* have this awful, painful schism between power users and basic users, and as you'll see further down in my post, I believe I have a middle road. I can say one thing for sure, though: if you *only* cater to the average user, and the *only* way to achieve the less-common use cases is by modifying the source, you're going to get a lot of forks from fed up developers who need to scratch an itch. Or, if they're not feeling up to the programming task, they'll just switch desktops, or run Windows, or something. When you consider the high cost of losing a developer who might contribute to your platform, this is not something you can really afford to do with any regularity. Think about it from a benefit-to-the-project perspective: is it more beneficial to have one developer on the project who contributes code and patches, or is it more beneficial to have 50 happy end-users? If you had to choose one, which one would you choose? Well, I'm sure that some people might choose the 50 users, but me, I'd choose the developer for their ability to give back to the project. Again, though, this is an awful choice to have to make. Why can't we do something that makes everyone happy? Maybe we can! Here's a thought that may not have occurred to you: plugins. In my opinion, plugins provide the best of both worlds: the default install can be pared down and minimal so that new users don't get confused, while advanced users who know they have the need can discover the plugins and install them. I have written plugins for Rhythmbox and find this model to be most excellent. Rhythmbox, out of the box, is fairly simple; and can be made even simpler if you disable the plugins that are installed by default. Now, if all the plugins ever written for Rhythmbox were part of Rhythmbox *core*, and all of them had some kind of checkbox somewhere as an option, that would be fairly annoying, even for power users! But the plugin nature of Rhythmbox makes it very easy to get extra functionality by googling for it, or searching Ubuntu Software Center, for instance. Based on my experience working as a plugin developer for Rhythmbox, here is my viewpoint: You are writing a piece of software, or maintaining an open source project. You realize the potential for some feature to be implemented. This is a feature that you don't want to automatically be built-in to the application with no way to turn it off, because you know that some people will want it, and some won't. Now, you are at a four-pronged fork in the road: Choice 1: Implement the feature directly into the application with no way to turn it off. This is dangerous, because user pushback of "it's too complicated!" or "it's annoying!" is likely. Choice 2: Don't implement the functionality AT ALL. This is also dangerous, because power user pushback of "this app is useless!" or "it doesn't have the features I need!" or "I'm going back to Windows!" is likely. Choice 3: Implement the functionality buried in some preferences pane or menu option. This is not a terrible idea, but once you start having dozens or hundreds of checkboxes and dropdown lists and toggle buttons, the user gets overwhelmed. Even a power user, when first running your app, will get overwhelmed. Your app will be popular, but will have a small niche community of power users who love the options and understand the nuances of each one. These users will have a great time, but the rest of the 90% of the potential user base are locked out because they can't get past th
Re: Unity Going Forward
It's not necessarily just old systems that will hit this, by the way. New systems with the latest generation AMD or Nvida GPUs can just as easily hit this snag due to lack of open drivers support. For example, even to this day there is no real 3d support for Radeon HD7000 series except for fglrx. Will Ubuntu be able to detect these cards and enable the restricted drivers automatically with no prompting, or will it fall back to llvmpipe when the Mesa stack fails to support your card? Anyway, on brand new systems there is less of a concern, because the performance of llvmpipe on a current-gen CPU is almost tolerable. By contrast, the systems that are so old that the hardware doesn't support OpenGL 2.0 probably also have a CPU that will render llvmpipe a 0.1fps slideshow due to lack of SIMD instructions, which boost llvm's performance tremendously if available. Further optimization work on llvmpipe may yield better results, but eventually you will hit a wall where software rendering is as fast as it can be - - and on the kind of CPU that was in production back before OpenGL 2 was deployed, getting it to an acceptable FPS is going to be close to impossible, I think. The worst part is that we won't even be able to address the user complaints that "Ubuntu is horribly slow" after we hit that software rendering performance wall. But if we can somehow warn these users off of using the main Ubuntu distribution and have them use Xubuntu or Lubuntu instead, that might be in everyone's best interest. On Aug 16, 2012 8:52 PM, "Jason Warner" wrote: > *Hi Everyone - > > Today is the first day that 'Unity' can be used without confusion on > Ubuntu. Unity 2D has been removed as a default option in favor of Unity 3D > across the board. This is a work in progress, so bear with us as we sort > out the details in the transition. > > What does this mean? First and foremost, it means we have one codebase > going forward. Secondly, it means that that there will be some regressions > in use cases where Unity 2D fit in the past. Lastly, it means you should > see a unified experience wherever Unity runs. > > Ever since Unity was introduced there have been slight gaps in the > experience between Unity 2D and Unity 3D (forever forward called Unity). > With one code base for all form factors we can guarantee a unified > experience. One code base also means we should be able to move faster as we > don't have to split the effort anymore, further accelerating our pace of > innovation. > > But there is a cost to this decision. Unity 2D fit a very specific use > case in very low-end and non-GPU accelerated hardware. By consolidating to > Unity using LLVMpipe for this specific use case we expect to see some > regressions in systems supported. This means that a certain class of > hardware will no longer be supported to run Unity. Unity will run on all > GPUs that support OpenGL 2.0. The earliest GPUs that meet this requirement > are at least 5 years old[1]. Even so, we know some subset of cards and > hardware that could previously run Unity 2D will no longer be able to run > Unity. > > For these cases, we are actively working on Unity running through LLVMpipe > which is a work in progress. Unity through LLVMpipe is CPU bound which > means systems with decently modern CPU architectures and non-GPU > accelerated hardware should be able to run Unity. As I mentioned, this > approach is a work in progress as we tweak the experience and effects to > maximize the performance. We expect this to shake out over the rest of this > cycle and bleed into 13.04 as well[2][3]. > > Still, with all the above, there will be systems that are simply too old > to run Unity. In those cases it would be necessary to either stick with > 12.04 LTS or run another desktop environment[4]. > > We want this transition to go as smoothly as possible and are working on > supporting as much hardware as we reasonably can. Hopefully we should have > most of the wrinkles worked out by 12.10 release with just a little > hangover for 13.04. > > Thank you, > Jason > Ubuntu Desktop Manager > > [1] - Unity will run on GPUs with support for OpenGL 2.0 > The earliest GPUs meeting this requirement are at least 5 years old > Intel i915 > NVIDIA GeForce 5200FX and up (5200, 6xxx, 9xxx, xxxGT(X/S)) > ATI Radeon 9000 and up, maybe earlier (9000, X1xxx, HD) > > By chip series rather than model series: > Intel: i915 > ATI: R300 chip series > Nvidia: NV30 chip series > > [2] - We know Unity is showing some graphical corruption inside a VM. Work > to correct this has been done but not landed yet. > > [3] - We know Unity won’t work right now on ARM. A solution is being > worked on and should be ready shortly, hopefully before feature freeze. > > [4] - > http://askubuntu.com/questions/65083/what-different-desktop-environments-and-shells-are-available > * > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > > -- u
Re: [Desktop 12.10 Topic] The future of third-party driver installation
On Thu, Apr 19, 2012 at 7:56 PM, Jo-Erlend Schinstad wrote: > Den 18. april 2012 09:14, skrev Martin Pitt: >> Hello Desktop fans, >> >> We have had Jockey for quite a while now to perform the installation >> of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. >> fglrx-updates), third-party (e. g. from openprinting.org) drivers. > > Hardware! Yes, that's an area where large improvements can be made. > > The ability to easily install third-party drivers is obviously quite > valuable. But how do people actually look at drivers? I don't think most > people understands the difference between open drivers and proprietary > third-party drivers. Nor do I think they care. And why should they? What > they want, is for their hardware to work properly. Hmm. I think you should be careful not to jump to conclusions here. You may run into a lot of trouble coming to consensus among the community, or even among the Ubuntu developers, regarding this point. Don't take it for granted that everyone will turn a blind eye to proprietary software running on their system. A lot of people think it is important to remind our users that the *reason* why their OS runs so well is because the vast preponderance of its software is free and open source software. Licensing matters -- whether or not you agree with that point, licensing nonetheless matters to a lot of people, and whitewashing the subject will not be an easy sell. All I'm saying is that you're touching on a very controversial issue here, and regardless of what I personally believe or how convinced you may be of your own opinion, realize that you can expect resistance from various people if you're going to say "why should users care whether their drivers are open source or proprietary?". People will give you reasons why -- reasons that they feel very passionately about. Just be prepared. ;) Instead, a good compromise would be to provide the user a summary of the pros and cons of using proprietary drivers without making it overly complex. You almost have to take it on a per-driver basis, because it really does vary (aside from the fact that Ubuntu developers can't directly support or enhance or fix bugs on proprietary drivers; this point is going to be the same for all proprietary drivers). But for other drivers like fglrx, there are issues such as whether kernel mode setting is supported, the expected 2D performance, the expected 3D performance, the expected stability, and so on. If we could somehow capture these points in a user-accessible way and allow the user to make an informed decision, that would be better than trying to *over-*simplify and make a decision for them, whether that decision is in favor of open drivers or proprietary ones. Because remember, it's hardly a foregone conclusion that proprietary drivers are always going to work better or be more stable. It really depends on the use case. For instance, there was an EIGHT MONTH period where I could get a solid 60 fps with 100% stability from the radeon open drivers playing my favorite game (Savage 2), but it would crash on startup with the proprietary fglrx. This continued, as I said, for eight successive monthly releases of fglrx. But on the flip side, there were many applications that would lock up the whole system if started with the open drivers, but fglrx would render them decently well. We're going to be shipping drivers with really nasty tradeoffs like this for years and years to come, and if we don't deal with the complexity, the users will deal with it the only way they can: they will ignorantly claim, "Ubuntu sucks!" as soon as their system or some program crashes for *any* reason. Complex problems require complex reasoning, even with licensing itself completely out of the picture (and the licensing debate will open a whole new can of worms by itself). > > If this was going to be redesigned, I would rather see it as a "Hardware > manager". Ubuntu is currently promoting drivers as an optional extra. > But that's not true; drivers are always necessary for all hardware. One > problem with doing that, is that when you're missing an important driver > and it's not available in Jockey, then you get the impression that > Ubuntu has no drivers for your system. Reality is that Ubuntu has nearly > all of your drivers, but missing one. Users should see that. Otherwise, > we're always reinforcing the negative without showing anything positive. > The moon looks smaller when it's near the horizon, because you have > something to compare it to. So let's compare the one thing that doesn't > work with the huge number of things that does. Are you basically suggesting a shameless clone of the Windows Device Manager? Not a terrible idea, if it can be executed well. And I mean *well*. Linspire had a similar thing a few years back, but it was abysmal: you couldn't get any real information from it, and the information that *was* there was very technical and inscrutable to end users. It also didn't tell you whet
Re: It's time to jettison CCSM
On Thu, Jan 26, 2012 at 11:28 AM, Jorge O. Castro wrote: > With tools like MyUnity now in universe, and didrocks putting basic > configuration in the control panel I'd like to propose the removal of > compizconfig-settingsmanager. > > I don't mean "stop telling people to use it" or "add a warning", I > mean total removal from the archive until the tool is either better > tested or doesn't break people's configuration. Here are some of the > problems with the tool. > > - It's possible to accidentally uncheck the Unity plugin, breaking the > user's desktop. > - It has a load of checkboxes for plugins that we don't support, > allowing infinite combinations of untested options, which result in > either a broken desktop or a misconfigured one. > - People report these bugs, and instead of fixing real bugs we have to > deal with corner case bugs for things we never plan on supporting. > - Since it's settings are separate from Unity a "unity --reset" > doesn't fix it, you have to blow away .compiz or some other dotfile > directories to get a desktop back. > - Alex Chiang has documented some of the issues he's run into here: > http://askubuntu.com/a/80590/235 > - I'm sure at UDS you've seen didrocks show you one of the ways it > breaks even when using parts of it that shouldn't break. > > MyUnity is a better user-facing tool anyway for those that want to > play, it would be a shame to have the ccsm tool ship in an LTS. If > anyone cares about it they can plop it in a PPA. As someone else already mentioned, I'm in favor of adding dpkg rules that prevent installation of CCSM alongside Unity. Why prevent people using Xfce, LXDE, Mate, etc. from using CCSM, when it's far less buggy when it's not interacting in destructive ways with Unity? Removing it from the archive does not seem like the Ubuntu way at all. Rather, I can practically guarantee you that there will be a huge rallying cry in the power user community that removing it was unfair and poorly thought-out, and that this outcry will spread to regular users who don't understand the situation in the first place. If you want to work on MyUnity or whatever to get it up to feature parity with CCSM, please do so. But Ubuntu has jumped the gun on the issue of "what we have is bad but featureful, so we're going to replace it with something that's good but feature-deprived" on more than one occasion, and *every single time* the distribution loses users and suffers publicity setbacks. Especially for an LTS, I just can't get my mind around how this makes any sense at all, particularly for distros like Xubuntu and Lubuntu where compiz can spruce up an otherwise spartan desktop. OTOH, if you just make it so that apt and dpkg won't permit installing CCSM when Unity is installed, you're completely solving your original problem, which is to prevent users from installing CCSM and breaking Unity, while allowing the tool to be useful for other desktops. Of course, *someone* is going to try downloading the deb and running dpkg --force, but by the time they've gotten to that step, they're essentially accepting any risk of system breakage that may result. You can't protect users from themselves on an open source platform; it is simply not possible, not advisable, and far more likely to cause a backlash in the attempt than to lead to a more stable distribution. Honestly, I think "Ubuntu is broken" is by far the lesser evil compared to "Ubuntu is ignoring the needs of their users" (this latter one WILL come up on very popular websites if CCSM is removed from the archive). -Sean > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Screen recorder - Kazam
Hi, On Sun, Jan 1, 2012 at 5:59 AM, David Klasinc wrote: > Thanks for the response Sean, > > On 12/31/2011 09:03 PM, Sean McNamara wrote: > >> Very cool! While I completely agree that these codec choices should be >> the default, is it easy for the user to configure Kazam to use some >> other codec? I'm not saying VP8/WebM is bad; rather, I'm saying some >> other codecs may have their uses (e.g. if you intend to distribute it >> as a raw video and you want the highest platform compatibility, VP8 is >> still not that heavily adopted on older Windows systems, or even older >> Linux distros). And the quality will be much higher if it is encoded >> directly to the format that you intend to distribute it in, rather >> than performing lossy transcoding. > > VP8 is a trade-off between quality and availability. Codecs and their > support in most modern Linux distribution is still a nightmare. There > are different versions of libraries that support different sets of > parameters and options. VP8 is something that is available everywhere > and has a decent support in GStreamer. > > Kazam initially encoded videos with ffmpeg and used libx264 (getting > this to work on Linux is not an easy task even now. You have to build > ffmpeg from source because of all the licensing and patent issues. > > Personally I would prefer H264 over VP8. H264 is better, performance > wise and quality wise. VP8 is still a resource hog and encoding full > screen video with more than 15 fps in realtime can be challenging. > > In the long run I want to support different codecs with some kind of > auto detection what is available and what not. IMHO you shouldn't directly use ffmpeg, libx264, or any other library. For all of your media needs, just use GStreamer. GStreamer has gst plugin wrappers for all of the useful ffmpeg codecs (gst-ffmpeg), and it has plugin wrappers for all of the important standalone codec libraries (including x264). The challenge is getting the user to install them. ;) For starters, you could add most of the gstreamer plugins packages as either suggested or recommended in the Debian source package. If the packages somehow don't get installed automatically (they would get installed if you Recommend them and install Kazam with apt-get), you could write a simple "Available Codecs" screen as part of Kazam, which iteratively goes through a pre-defined list of plugin classes trying to use gst_element_factory_make() on the name of the class, and if there is an error you can report that the codec is missing to the user. As long as you have at least one supported video codec and one supported audio codec, you can proceed to allow the user to use the app, but you would want to make them aware that some of the supported codecs aren't available due to missing packages. If you're feeling really adventurous, you could even add in a button for the user to click, to use the gstreamer packagekit integration to automatically download and install missing codecs using apt. That functionality works _reasonably_ well on modern distros with a working policykit implementation; it works the best if the user has repositories enabled which have proprietary codecs (because otherwise packagekit won't be able to find any proprietary codecs that the user wishes to install). So I believe x264 would automatically be out on Fedora without using a third-party repo, but on Ubuntu, I think it's there in gst-plugins-ugly in multiverse or restricted (correct me if I'm wrong). To get a sense of how to structure your code, and the kind of logic you'll need to robustly wrangle Gstreamer codecs, you might want to take a look at some of the software that uses GStreamer for transcoding, since you're using it for a very similar purpose: http://gstreamer.freedesktop.org/apps/ (Unfortunately, the software I wrote, rbpitch, does not do a whole lot of poking around with plugin discovery etc, so I don't have existing working code in Vala for this functionality.) > > >> The best place to get started is to read >> https://wiki.ubuntu.com/ContributeToUbuntu -- and follow the links >> from there. > > I'll take a look there. Hopefully I can find a checklist document about > inclusion in the distro. :) > >> Although if you are able, and there are no really challenging >> roadblocks, you should go ahead and try with GTK3. > > I'd like to get rid of GTK2 as soon as possible. :) This is the very > first thing on my agenda after I deal with the codec issues and ffmpeg. > >> Are there any really low-level GTK2 APIs that Kazam uses that might've >> been removed or significantly changed in GTK3? I guess I could read >> the source, but I'm getting ready to head out the door right now, >>
Re: What I love about Unity
On Sat, Dec 31, 2011 at 11:58 AM, Ted Gould wrote: > On Fri, 2011-12-30 at 23:03 +0100, Jo-Erlend Schinstad wrote: >> Den 30. des. 2011 20:30, skrev Ted Gould: >> > Thanks for writing this up. I appreciate it. We're never perfect, but >> > it's nice to see some positive reviews every once in a while :-) >> >> It was not meant as a positive review and I don't want it to be >> understood as such. > > Sure, it wasn't a review really. I guess it should have read "noting > some of the positive aspects." Though, in general, I was less careful > with my words since I wasn't replying to the mailing list ;-) > >> The point was to separate between what users see and >> what programs see and why that's important. The ultimate goal for me, is >> to teach everyone that there are no fundamental differences between >> 10.04 and 12.04. > > > In general, you are correct, but I think your language there might hurt > your argument. I think that, for most people, it seems drastically > different because the data is presented in a different way, but it is > fundamentally the same data. So instead of saying "nothing changed" it > might be easier to say "only the emphasis changed." > > As an example we could look at the use case of finding applications. > You can still browse for the applications in groups like you could in > the Applications menu of 10.04. But, it's not as handy. On the flip > side searching them is much, much, easier. So we've switched the > emphasis from browsing to searching. Switched the emphasis? You mean to say that there is actually a way to browse applications by category in Unity, similar to how the menus were structured in Gnome2-panel? Well, that's news to me, and I've used Unity on 11.10 for tens of hours in a virtual machine while testing my software for Ubuntu compatibility. I would sometimes get pretty fed up with having to type in the name of the application I wanted to launch, instead of just clicking through a few menus. And scrolling through the huge list of applications (I accrued many, many of them because of all the development packages etc) is not convenient, either; nor is it particularly snappy. If this is in fact an explicit feature of Unity, I'd like to know how to access it! I think one of the biggest flaws of Unity isn't a flaw of the software at all, but of the human beings who use it (remember, Linux for human beings?) -- 80% of the users don't know about 80% of the hidden nugget features of Unity, because it's new, different, and likes to "hide" a lot of stuff behind the obvious veneer. So yeah, your attempts to "emphasize" one thing over another have essentially produced a piece of software where the vast majority of the people will only see the obvious features that you stick right under their nose; and if they happen to desire a feature that's in any way occluded or hidden behind a hotkey or whatever, they simply will never ever use that feature because it's not apparent to them. Again, probably not a software flaw as much as a human flaw, but that's how it is. Imagine shipping Ubuntu with a Unity tutorial video on the CD, or (if that makes the CD spinners cringe at the file size of such) a video player that pops up and streams the video from the internet Or even, a *series* of videos: one for beginners that just enumerates the most obvious, basic stuff, and two or three more that go more and more in-depth with hotkeys and things that most people don't know about. Your biggest challenge for Unity is similar to what others before you (PulseAudio, systemd, etc) have faced: user education. So educate the users, in an accessible, highly-visible manner! Nobody's going to read the manual; I'm sorry but that just doesn't happen. A video is probably the best way. -Sean > > --Ted > > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Screen recorder - Kazam
Hi, On Sat, Dec 31, 2011 at 2:23 PM, David Klasinc wrote: > Greetings, > > Recently I picked up Kazam Screencaster. I needed to record something > and noticed that Kazam is not working and has some dependency issues in > Oneiric. After trying out few other solutions none of them really suited > me. Around Christmas I started working on Kazam and made some > improvements while solving those dependency problems. > > Andrew Higginson stopped working on the project and made me a member of > Kazam team on Launchpad so I can take over from here. Cool! Congrats on volunteering to maintain this project! :) I'm not familiar with Kazam, but I'm learning about it now, since it seems interesting and useful... > > https://launchpad.net/kazam > > Right now most of the development is done in my PPA until I get things > stable enough and merge them in the stable branch of the project. > > https://launchpad.net/~bigwhale/+archive/kazam-oneric > > (yes, the typo should be there :/) > > Quick rundown of changes that I made: > > - Default backend is now gstreamer. > - Video is encoded with vp8 instead of x264. > - Audio is encoded with Ogg Vorbis. > - Audio/Video container is now WebM. Very cool! While I completely agree that these codec choices should be the default, is it easy for the user to configure Kazam to use some other codec? I'm not saying VP8/WebM is bad; rather, I'm saying some other codecs may have their uses (e.g. if you intend to distribute it as a raw video and you want the highest platform compatibility, VP8 is still not that heavily adopted on older Windows systems, or even older Linux distros). And the quality will be much higher if it is encoded directly to the format that you intend to distribute it in, rather than performing lossy transcoding. > - Package dependencies revised to include only essential packages. > - Basic Pulseaudio support. > - Independent audio input device selection > - Volume setting slider in the works > - The path to multiple source recording is now open. Next release should > support recoding audio on two channels (application sounds and > voice-over commentary, for example). > > Currently Kazam is still GTK2 and I'd like few pointers on what needs to > be done if I want Kazam to be included in the Ubuntu repositories for > Precise Pangolin. And if I missed the mailing list, someone please kick > me in the right direction. :) The best place to get started is to read https://wiki.ubuntu.com/ContributeToUbuntu -- and follow the links from there. You're already very far along because you've already: -Written the software -Created a source package for DPKG -Put it in a PPA -Communicated with the community announcing your package and soliciting feedback This is a very large step in the right direction. The rest, as they say, is testing/validation and politics. :) Also I'm not 100% sure but you can probably get it accepted into Precise (in Universe, dunno about Main) with a GTK2 UI. The GTK2 libs will continue to stick around for years and years (and years) to come. Although if you are able, and there are no really challenging roadblocks, you should go ahead and try with GTK3. My general porting strategy for GTK3: 1. Build against the gtk3 libs and headers in your build system (easy) 2. Fix any compilation errors (can require some rewriting, but not that much usually) 3. Fix any linkage errors (can be painful if your favorite API is gone) 4. Test it out like crazy to make sure that everything works equivalently at runtime (time-consuming but easy) Are there any really low-level GTK2 APIs that Kazam uses that might've been removed or significantly changed in GTK3? I guess I could read the source, but I'm getting ready to head out the door right now, so... Anyway, Happy New Year to you as well, and thanks for working on this and being interested in contributing! Disclosure: I am not an Ubuntu Developer, though I do host a project on Launchpad, package it in a PPA, and have expressed interest in getting it into Universe in the past... so we are pretty much at the same stage :) Regards, -Sean > > > (more detailed explanation on my changes and future plans are posted on > my blog: http://www.twm-kd.com/linux/kazam-screencaster-0-12/ ) > > So much for now and a Happy 2021 to everyone! > > Regards, > David > > > > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubuntu usability is significantly decreased with Unity
Hi, On Wed, Dec 28, 2011 at 6:55 PM, Nenad wrote: > On 12/28/2011 09:38 PM, Jo-Erlend Schinstad wrote: >> >> Den 28. des. 2011 20:40, skrev Nenad Lecek: >>> >>> Dear all, >>> >>> as I don't know where to put my comments about Ubuntu 11.10 usability, >>> I'm posting here. My apologies if this is not the right place, and I'd >>> be grateful if you point me where to post my comment. >>> >> >> This list is ok to use for discussions about the desktop, but you should >> back up your claims with facts. It is not a fact that Unity doesn't >> serve users well. It serves me well, for instance. Claiming that Ubuntu >> is no longer user friendly because you don't like one of the >> applications it provides, is pure nonsense. > > > well, I'm using Ubuntu 11.10 and found really annoying to use Unity. > Open several windows (e.g. Netbeans, firefox, nautilus and gitk and try to > work efficiently with menus of each application, minimize/maximize window, > etc., Unity is just driving me crazy. It is simply unnatural. In case the > Unity is just one application that is seldom used, and not the central one, > you won't get my comments for sure. Please remember that the definition of "natural" depends on what each user is expecting, what they're used to in prior computing experience, etc. Unfortunately, Canonical and other organizations have done user studies on the Gnome2 interface with people who aren't familiar with computers _at all_, and found that Gnome2 is extremely counter-intuitive for them, and takes a long time to learn. So as you can see, every desktop you could possibly design will be unnatural for _someone_. Not even the most intelligent User Interface researchers have found a way to objectively define "natural" in a way that it's true for all human beings. Your own words serve to prove the point: although Canonical made their best effort to make Unity natural for a lot of people, and at least tolerable for almost everyone else, there are still going to be people who absolutely abhor it. (Self included.) Although I just admitted that I hate Unity in terms of its actual usability from *my* personal point of view, you might be surprised to hear that I don't think it should be replaced as the default desktop on Ubuntu! I think it should stay for the following reasons: 1. It makes Ubuntu unique. A distro that doesn't stand out is far less likely to receive user loyalty and an above-average level of users, because users will be able to have an equivalent experience elsewhere. Sure, you run the risk of alienating users for being different; but that's OK as long as the number of alienated users is very low. 2. I'm fairly confident that Canonical has done extensive usability studies on new users (their main target market) and found that people in the poor computer literacy category find it better than Gnome 2, if not downright enjoyable. New users are the best opportunity for Canonical, because they don't already have a ton of programs that only run on Windows or Mac that a more experienced user would naturally refuse to part with. 3. It's already there. Going back to Gnome would make Canonical the laughing stock of the internet, for investing tons of money in a new desktop, and then giving up on it and going back to the primarily Red Hat and Novell-funded GNOME panel. Being "wishy-washy" is NOT a good way to inspire confidence among the technically elite, who you absolutely must have on your side to be successful (as some criminal once said, "Developers, developers, developers..."). 4. It makes the distro choice completely obvious for those accustomed to Gnome2. I have to thank Unity for making me try other Linux distros instead of being satisfied with Ubuntu. I am completely happy with Fedora, and have no intention of looking back. If Ubuntu had made it blindingly easy for me to click a "Gnome Panel" radio button at install-time, I might have never consciously thought that Ubuntu's ability to satisfy my needs has reached unacceptable levels, and I might not have discovered the awesome that is Fedora 16. I consider that as Unity being helpful in its own way. ;) 5. Everyone at Canonical uses it to do development every day, so clearly it is very productive for developers and power users. ;) OK, so some of those are expressing my own frustrations in a satirical, tongue-in-cheek manner. Sorry if I stepped on any toes. I really actually like Canonical as a company, and have pleasantly done commercial business with them in the past. In fact, I think LaunchPad is an amazing piece of software, and I use it regularly for my own open source projects. I prefer Bazaar over almost any other version control system (except Git, but there's no shame in losing out to Linus Torvalds!). PPAs are a remarkable and easy to handle way for distributing binaries. Canonical has had lots of great ideas and has executed some of them extremely well! :) But not Unity -- not for me. So because I didn't have the patience to go back and fix Ub
Re: Default Desktop Experience for 11.04
On Mon, Apr 11, 2011 at 7:25 PM, Jo-Erlend Schinstad wrote: > On 11 April 2011 13:22, Scott Ritchie wrote: > [snip] >> I think it's the height of arrogance for us to tell a user that we're >> going to deliberately break his application because it wasn't updated to >> use our new indicator library. "Still working the way it used to" is a >> reasonable fall back. > > I don't agree with that, actually. It feels strange saying that, > because I'm really for long-lasting software. But sometimes, you just > have to break compatibility if you want to achieve something big. If > the discussion was about removing support for the old notification > area icons in gnome-panel, I would agree. That would be really > arrogant since people actually use and depend upon it. But this is new > software and everyone agrees that those icons are something to dispose > of. Do we really want to keep polluting the environment just in order > to be backwards compatible? That doesn't seem wise to me. Where is the empirical evidence that even a simple majority of users would prefer not to have icons in their system tray? This kind of decision seems like one of those things that's decided in a vacuum with a lot of hand-waving and culture bias (asking your coworker, etc) rather than a genuine conclusion involving a representative set of opinions of real end-users out there. It seems to me like an underlying motivation for the system tray to go away mainly because they want more room on the top panel of Unity for application menu items. If you have an app with 6 or 7 or 8 menus (just try LibreOffice) on a reasonably small screen, the menus will get cut off if you have bunches of system tray icons. This is a really silly reason to want to get rid of a perfectly useful feature of the operating system: we need more space for something else? This makes no sense to me. I like how Gnome3-Shell handles systray icons. They show up in the bottom right if you hover your mouse near the bottom right corner of the screen. This action of moving the mouse to make something pop up is shared between Unity and Gnome-Shell, so I don't see why Unity can't be made to do the same thing. The best part is that the icons don't occupy a permanent part of your screen real estate (essential for small screens); there is potential to make it "always show" with a toggle or GSettings flag; and applications don't have to alter their de facto systray icon practices at all. It's a win-win. > > I don't think it's arrogant to be zealous in the pursuit to disable > bad ideas from polluting our work environment. Sometimes bad ideas > have to be actively discouraged if we want to have progress. There is > nothing to prevent an application from supporting both the old ways > and the new ones. There is no conflict. There is no problem. > Certainly, it is not arrogant to have visions that becomes goals, to > set standards and to hold them dear. This is the kind of thinking that got Rhythmbox to remove the 'stop' button, and make it more convenient to type 'halt' into the root console than shut down the computer using a GUI? No thanks. Just my 2 cents. Sean > > If anything, I'd like more of that in the freedesktop world of ours. > > Jo-Erlend Schinstad > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Default Desktop Experience for 11.04
Hi, On Sat, Apr 9, 2011 at 2:16 PM, Jorge O. Castro wrote: > On Sat, Apr 9, 2011 at 12:43 AM, Sean McNamara wrote: >> As a long time Gnome2 user (and prior to that Windows), I agree that >> not having the Windows-style "taskbar" is rather jarring for someone >> used to having it. Changing between windows in Unity is a mystery, and >> if you are running more than 2 applications it becomes unmanageable >> and takes way too much time for multi-taskers. > >> The answer to this question is a function of the user's screen >> resolution / number of monitors. For a small screen single-monitor >> setup, the answer is probably "Yes, the strengths shine quite well". >> For workstations with large wide-screens or multi-monitor, the answer >> is probably "No, the weaknesses are overwhelmingly bad". > > Having used Unity all cycle with multiple monitors and apps I find > this feedback surprising. I was going to go point by point addressing > how multitasking works in Unity, but instead I made a video of how I > use it to highlight my points. If anything to me Unity feels like > GNOME 2.x multitasking on steroids: > > Web: http://castrojo.blip.tv/file/4997614/ > Download: http://blip.tv/file/get/Castrojo-HowIMultitaskInUnity835.ogv I really enjoyed this video, Jorge! You taught me a few things I didn't know, and made it all look so easy. Maybe the problem is with me as a user, acting like an old curmudgeon, too used to *clicking* on windows in the taskbar at the bottom of the screen, and not being able to get my head out of this paradigm. If that's all it is, well, that's no good reason to keep back Unity! I'll give it another serious look this weekend and let you know if I get used to the keyboard shortcuts. I've spent 5 or 6 years training myself that the super key is useless under Linux; time to reverse that perception. BTW, you should tout this video far and wide. I'm sure the folks at OMG! Ubuntu would love this. Thanks, Sean > -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Default Desktop Experience for 11.04
Oops -- I meant to send this to the whole list, not just to Timo! Sorry for the double mail, Timo! Sean On Sat, Apr 9, 2011 at 12:57 PM, Sean McNamara wrote: > Hi, > > On Sat, Apr 9, 2011 at 5:07 AM, Timo Jyrinki wrote: >> 2011/4/8 Timo Jyrinki : >>> There are a lot of bugs and lack of features (and many have been fixed >>> already as well) and the performance is quite bad in parts, but those >>> are not as serious as a) crashers and potentially b) accessibility and >>> lack of any help. >> >> Just reflecting on the more recent posts, I'm using Unity on my work >> machine, but I do have only 1280x1024 (or 1400x900, depending on if I >> use internal or external display) resolution. I mostly run everything >> full screen, and most of the time I don't use Unity to switch between >> windows at least yet - I use either alt-tab (somewhat annoyingly slow) >> or compiz's scale plugin which I have bound to lower right corner of >> the screen (works pretty nicely for me). >> >> As for "what I say to others" factor, I (and Ubuntu Finland website as >> decided by us already around 10.10 time) continue recommending Ubuntu >> 10.04.2 LTS for everyone. I don't believe users should generally >> install a non-LTS Ubuntu, even with the caveat of not the newest >> hardware support. 18 months of security support and therefore need to >> upgrade N number of times to get to the next LTS is too much for many, >> since the upgrade is still something of a hassle at times, regressions >> appear et cetera. > > I don't think it makes sense to lower the quality bar for Ubuntu > non-LTS stable releases. If you want to put something out there that's > rough around the edges, that's what alphas, betas, and (to some > extent) RCs are for. Stable releases should be just that; stable. If > Unity can't meet everyone's expectations for quality, it shouldn't go > into a release by default, whether it's an LTS or not. > > I know a lot of developers stand by the argument that, in order to get > enough testing and popularity for their software to be successful, it > needs to be released by default to the general public in a major > distribution. I've heard appeals to past experience with things like > PulseAudio and Empathy. While I agree that using the general public as > a massive test bed can be beneficial to software quality, it also > harms the image of the GNU/Linux desktop at the same time. When things > don't work right, users don't understand why: they don't care why, and > they don't want to know. They only associate the product they were > using with terms such as "buggy" or "unusable" and move on. This > really hurts our progress towards resolving Bug #1. > > Aside from that, PulseAudio was somewhat of a special case: its > primary growing pains could *only* be resolved by widespread testing. > The problem was that ALSA didn't have the necessary quirks for a great > number of sound cards out there, resulting in incorrect volume > information and timing in PulseAudio. The key point is that *no other > software before* had ever tried to use ALSA like that, so the bugs > were exposed left and right. Can we say the same thing about Unity and > the open source graphics stack? I don't think so. > > The issues you see with Unity vs. Mesa/KMS/Xorg/etc. manifest > themselves in plenty of other programs, including running compiz on > Gnome2; Mutter on Gnome3; and a smattering of OpenGL 3d games. We > already ship the OSGS by default for many years, so it's already > getting exposed to a wide audience, and advanced 3d is being tested to > the extent that users try to enable compiz and/or play 3d games. It > appears that the main benefit of widespread Unity testing in a stable > release -- that of getting a wide array of hardware to test it on -- > is kind of redundant, in light of other programs already testing out > the graphics stack for years now. The consensus has always been that > the OSGS is woefully inadequate, and any improvement we've seen in the > past few years has been completely orthogonal to the development of > Unity. > > So my opinion is, spend as much time as it takes working with a > smaller group of enthusiasts, early adopters and developers to perfect > your software prior to releasing it to a channel where millions of > people will try it. Ubuntu is the most-downloaded distribution, so the > software quality contained therein reflects strongly on the public > perception of the quality of GNU/Linux and FOSS in general. If Unity > is crashing, lagging and behaving counter-intuitively on the &
Re: Default Desktop Experience for 11.04
On Fri, Apr 8, 2011 at 11:21 PM, NoOp wrote: > On 04/07/2011 06:38 PM, Rick Spencer wrote: >> Hello all, >> >> Back at UDS for 11.04 in Orlando, Mark set the goal of using Unity by >> default on the Ubutu desktop. Given the current course of development, >> it appears that we are going to achieve this goal, and Unity will stay >> the default for 11.04. > > Please reconsider. Despite the gush of greatness posts, I'd like to post > a usability comment as a user. > > For example (the same applies to most applications): > > I open SeaMonkey in G2 and keep multiple mail/news/browser windows open, > see: > > http://img840.imageshack.us/f/screenshot9sw.png/ > [click to enlarge & scroll to the bottom] > > I can easily click on any of those, or use Alt-Tab to change. > > In Unity if I attempt to do the same, I have to use the SeaMonkey menu > to select the window. I can of course use Alt-Tab, but afterwards I have > no immediate idea about which/how many windows I actually have open. > See: > > http://img820.imageshack.us/i/screenshot4wz.png/ > [again, click to enlarge] > > The inability to have that bar with windows that I can use is, for me, a > complete show stopper. As a long time Gnome2 user (and prior to that Windows), I agree that not having the Windows-style "taskbar" is rather jarring for someone used to having it. Changing between windows in Unity is a mystery, and if you are running more than 2 applications it becomes unmanageable and takes way too much time for multi-taskers. Surely the programmers of Unity would have realized this while running Unity and developing it at the same time; all the different windows you have to have open to develop software would surely expose the problem... e.g. terminal emulator; documentation sites / Devhelp; IDE / text editor; IRC for collaborative development; bug tracker... The fact is that Unity just doesn't scale for this kind of use case. But after using the "present" feature of Gnome 3 (just hit the Windows key on most keyboards), I don't miss the window list in the taskbar that much anymore. On my small screen laptop (1024x768), Gnome 3 + gnome-shell effectively eliminates the vertical real estate consumed by Gnome2's bottom panel. But the window decorations are still there (this is good, since I'm used to them), and the top panel is still there (which is good, since I'm used to it). So on Gnome 3 + GS we have *some* real estate savings, but we still have a lot of the goodies that we're used to from Gnome 2. I'm running Gnome 3 + GS on Fedora 15 Alpha right now, and I absolutely love it. It's got some of the space savings + nice effects + "cool factor" of Unity, without the usability trainwreck. Having used current builds of Unity and Gnome3+GS quite a bit in recent weeks, my conclusion is that I think Gnome3 has out-Unitied Unity! It seems to accomplish many of the same design goals as Unity, but it has stability, performance, wider free desktop community acceptance, and a more familiar interface for users of Gnome2 on its side. Unity seems to me like it has gone "too far" in adopting slick screenspace-saving UX idioms; the result is that it's nearly impossible to multitask efficiently. Gnome3 does not suffer from the same kinds of limitations, even though at first it would seem that Gnome3 has many of the same problems for old hands that Unity does. My pipe dream would be to drop Unity (or just ship it as an optional installable) and ship Gnome3+GS by default, falling back to Gnome2 if hardware 3d rendering isn't available. But I know that (1) this would be a very tall order to "turn the boat" so dramatically inside the space of a month for the 11.04 release; (2) it is almost guaranteed not to happen if only due to the immense pride of the developers behind Unity, and their proportional level of influence in the Ubuntu development process; and (3) breaking the time-based release schedule in order to give us sufficient time to switch out a major desktop component is even less likely to happen, simply because the whole point of a time-based release is to be, well, timely. This point applies equally to shipping Gnome2 by default as well, I guess (although it's less valid there because the Gnome2 environment of Ubuntu has been tested and refined extensively for years already). >Also, note that the lack of a top tool bar where > I can dock an application for monitoring cpu, temps, etc., with a single > glance is as well. Not to mention being able to launch an docked > application with out losing focus on the application that I am currently > using. I miss these things too, but for what it's worth, a top panel remains in Gnome 3, so there is hope that we can develop Gnome-Shell plugins to do these things in the future, if such features aren't already available. So not to belabor my point again, but if you like the fancy effects of Unity but want the usability of Gnome 2, take a look at Gnome 3. It'd be worth your time. > For example; if I want to launch Libre
Re: Call for Natty Feedback!
Hi, On Tue, Mar 1, 2011 at 2:58 PM, Jason Warner wrote: > Hello! > Natty Feature Freeze is here and A3 is upon us! Anyone following along > closely should see and feel a fairly stable and usable system, complete with > Unity and classic Gnome. > I'd like to hear people's thoughts on Unity...and I'd like it to be pretty > unfiltered and raw. In particular, I'm interested in seeing how people feel > about: > * The look and feel > * Usability > * Stability (knowing that we are entering a heavy bug fixing time!) > * Highlights and favorite features > * Perceived shortcomings and/or "wishlist" items > You can reply to this email if your feedback is general/conversational or > file a bug if you are experiencing a specific issue. Filing a bug with > 'ubuntu-bug unity' command would do the trick and would get seen by the > appropriate people for specific issues. > It will be fun to hear what everyone thinks! I look forward to seeing the > feedback. > Cheers, > Jason > PS. For those that like to navigate via keyboard (and who doesn't!), this > should be > helpful http://askubuntu.com/questions/28086/keyboard-shortcuts-in-unity/28087#28087 > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > > I'll gladly offer my feedback. I've been using (or trying to use) Unity since about Alpha 1 until the present. My overall experience with Unity is that it's too much, too soon. It doesn't feel ready. It isn't streamlined. Here are a few targeted examples. 1. It's too difficult to get the menu along the left to appear when I want it to, but it's all too easy to get it to stay when I want it to go away. I'm always fighting with it: sometimes I want to do something and it disappears for a reason I can't really understand. Other times I have done what I want to do, and it just stays on the screen until I actually left-click on the ubuntu symbol in the top left. Sometimes I have to click it multiple times. 2. Performance impact of using Unity vs. GNOME 2+Compiz is visibly measurable with Intel 965GM graphics. Now, 965GM isn't exactly the fastest chipset on the planet, but in a "full fat" laptop with 4GB of 800MHz memory and a Core 2 Duo, the plain old browsing/email/IM experience shouldn't lag. At all. But with Unity, I get substantial performance problems, especially scrolling the browser and task switching -- it's "jittery". Compiz seems fine when running with gnome2. 3. Many applications (especially Qt/KDE4 apps such as Quassel) have their menus stripped out by the global menus feature, but the menu doesn't appear at the top, either. IMHO this is unacceptable: there should be a strictly tested and enforced disjunction that if the menu cannot be rendered at the top for whatever reason, then it should be left alone in the app. Having the menu fail to appear at all is a showstopper, and asking all applications to change to be compatible is simply not going to be a solution. 4. Scrolling in the Applications overlay (the translucent one that is black and takes up most of the entire screen) is painfully slow, even slower than web browsing. Brings me back to 2007 when you could get about 1 FPS browser scrolling with EXA on the Intel drivers :) 5. Stability has been poor in my experience; I run into X crashes from time to time doing fairly mundane stuff that doesn't trigger a crash with Gnome2. 6. Multi-monitor seems totally broken somehow... on a 1024x768 laptop with a 1680x1050 VGA LCD attached, I get no menus and no indication that Unity is aware of windows on the large external LCD. And the left-side menu doesn't come up at all anymore. It seems like there is an empty space above the top of my laptop's screen where my mouse can go, but there is nothing up there -- I configured (using the xrandr-based Monitors applet) the big monitor to be to the right of the laptop LCD. 7. It isn't clear to me upon visual inspection as to how I can pull up a window that's open using the unity bar on the left. With Windows 7 or Mac OS X, there is a dedicated place and visual style to indicate that there's a window open and you can click it to get to that window. I don't see enough contrast (or something) for it to be obvious to my eyes which icons are "launch this application!" and which are "click me to get this application's window back!". So I end up using alt-tab a lot, which is slower than clicking a button. I really miss the Gnome2 window selector. I think I'd like Unity if it were much more polished, the bugs were fixed, robust support for multi-monitor, and less "fiddly" menu on the left. I think it needs at least another 6 months of development and testing. I have recently (in the past 2 days) reverted to Gnome 2 and uninstalled the indicator global menu stuff. I may try Unity and global menus again as things get more polished and bugs get fixed, but for now, it is not really usable, and causes too much frustration for me to even test it. I am much happi
[Proposal] rbpitch: Rhythmbox Plugin
Hello list, I have been working on a new plugin for Rhythmbox in my spare time for several months. The plugin allows the user to change the pitch, tempo, and speed of the music currently playing (each of these elements can be changed independently of each other). Since I am an Ubuntu user and fan, I have reached out to the Ubuntu (power-)user community to solicit feedback. They have provided many useful suggestions that I have incorporated into the design, ranging from bugfixes to new features. Interest in the plugin has been luke-warm according to the opinion of "the average user", but with very high interest by audiophiles and musicians. I once attempted to get the plugin integrated into Rhythmbox itself, so that anyone building Rhythmbox would automatically build this plugin if their system met the dependencies. However, here is the response to that question when I posed it to the maintainer of Rhythmbox (upstream): http://www.mail-archive.com/rhythmbox-de...@gnome.org/msg06285.html I have been in continual correspondence with Jonathan since that time, and it seems he still thinks that having yet another non-essential plugin in the Rhythmbox tree is just bad software design -- most programs ship their plugins separately, by definition. And I agree with him. But just because my plugin is not included by default in Rhythmbox, is no reason to exclude it from distributions, right? :) Here is the community response to my plugin, along with build instructions from me: http://ubuntuforums.org/showthread.php?t=1303297 I have also blogged about it periodically throughout development, with screenshots and various other reflection: http://tiyukquellmalz.org/blogs/blog7.php Anyway, a feature of Rhythmbox is emerging[1] that will make it much easier to build rbpitch and maintain it in a distribution as an out-of-tree plugin. The way out-of-tree Rhythmbox plugins are currently structured in Ubuntu, each one gets its own package. Observe the trend: rhythmbox-plugin-coherence rhythmbox-plugin-cdrecorder rhythmbox-plugin-rbpitch [hypothetical] What I propose is to include this package in Maverick. This will alleviate the complicated build instructions and the need for users to install development packages. Enabling it by default would be flattering, but definitely not a requirement. Having it included in the distribution would make me very proud, and would make the users of rbpitch very happy. It would also greatly increase the user exposure to this plugin. I have never built a new package for Ubuntu before, but my main confusion is that I don't know what the political / organizational process is for seeing this through. I can technically figure out how to create the Debian package scripts; but once I have that, what's the next step to get it included in Ubuntu+1? That is why I am posting here, the history of rbpitch and its current status: I would like someone to help mentor me through the process of getting this new package into Maverick. Presumably it will need to be evaluated on its merits before inclusion as well, but I have no idea who to petition for evaluating it in such a way. [1] --> I say "emerging" because it's not 100% there yet. Rhythmbox 0.13.0 has provided support for building Rhythmbox plugins written in C in an "out-of-tree" fashion. That means you can build them without integrating them into the Rhythmbox source code and build system. Contrast this with the status quo in Rhythmbox version 0.12.x and earlier, where you had to build C plugins "in-tree". The problem is that rbpitch is written in Vala. Vala plugins have the same requirements as C, except it also needs a little bit of a push beyond that: it needs (compile time only) language bindings. These bindings are not in place as of Rhythmbox 0.13.0, but there is a very good patch on Bugzilla that (hopefully) will get integrated into the next release of Rhythmbox, which will enable this. See https://bugzilla.gnome.org/show_bug.cgi?id=621246 Thanks, Sean -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
