Re: Screen recorder - Kazam
On 01/01/2012 07:47 PM, Sean McNamara wrote: 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. ;) gst-ffmpeg is terribly undocumented and I think there is no real need for me to use it. I need to support a handful of codecs, not every single one there is. x264enc didn't work because of unknown reasons at the time being and it really pissed me off because I know it used to work. Five minutes ago I realized why it didn't work and I got it working now. It was a serious case of PEBKAC ... To make it short, I was testing with a smaller window 800x800, H264 video size must be divisible by 2 and x264 starts counting with 0. : I'll hack x264 as an option. 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 Right now I have base and bad plugins as a requirement and this covers everything I need. For x264 I'll also need ugly plugins package. If that is installed everything should work. 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. This is a really neat idea. I'll probably make webm default and a requirement and x264 will be an optional feature. but on Ubuntu, I think it's there in gst-plugins-ugly in multiverse or restricted (correct me if I'm wrong). If I can read this page correctly and the information is valid, it seems that uglies are in the universe. http://packages.ubuntu.com/oneiric/libs/gstreamer0.10-plugins-ugly If you want to go with Python, I can't really help you with the implementation details, since I am only a novice at Python programming. But I can wish you lots of luck, and still help out with things like the overall codec approach. I'm still contemplating Python and Vala. I'll see what time will bring. :) I'm quite fluent in python so it would be my first choice. Vala, however, is becoming a defacto standard for Gnome development and that's why I am considering it. I'm allquixotic on freenode, so feel free to ping me. We can even create a new channel for Kazam! Not all that bad idea. I registered a channel, BigWhale will be idling there mostly. :) Regards, David -- 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
Le 28/12/2011 20:40, Nenad Lecek a écrit : Dear all, Hi, 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. Thanks for sharing your thoughts and experience about Unity, seems quite a lot got discussed already on the list with other replies so I will just give some extra informations IMHO, the Unity is unnecessary, harmful step in wrong direction. The Unity doesn't help to make user interface more intuitive. Even worse, it is not solely the issue of quality of implementation, the Unity design doesn't have potential to serve the user well. My recommendation is to make the Unity optional and certainly not default user interface for Ubuntu. Gnome Classic Ubuntu desktop really fits much, much better. That's your opinion and a valid one but not one that everybody out there share. User testing on different groups of people, including non technical ones, indicated that unity is seeing as a step forward and a better interface that the old gnome classic by most users. They find it better looking and easier to use. Now keep into account that unity is new, many of the flaws you list and other usability issues are known and will be worked, it just didn't happen yet. 1) Appearing/disappearing left side toolbar doesn't bring anything compared to Gnome Classic Ubuntu desktop and menu. Why? The next version of unity will have an option for not hiding the launcher (the left bar), if you don't like the appearing,disappearing you will be able to easily change it. Simply put if you know that you have couple of menus where you programs are, this is much better/faster than unnecessary dynamic/uncertainty which Unity provides. BTW, Classic gnome desktop we had in previous Ubuntu versions was really well structured. Unity doesn't provide that. The menus were never well structured no, - categories are not obvious for most people (what is the difference between accessories, system tools in the application menu and the system menus? where is the take a screenshot?) - the menus had too many items making it hard to find for what you want - if you like categories you still have similar categories as filters in unity Personally, I do not see the point of promoting Unity as the only desktop on Ubuntu, because classic gnome desktop was well structured and good enough. Eventually, only search capability like in Unity could have been added, although this functionality in Unity is far from good, currently is just minor convenience. 2) The application menu is shown in main menu toolbar. This is annoying at best, and from usability point of view very it is a really poor choice. That's a known issue and people are looking at addressing it. Note that it's only an issue for people who use the menus a lot, in most applications the toolbar icons should be enough for most actions. Look at somebody using firefox and how much they use the menus for example. That's not to dismiss the fact that it is an issue for some users, it's just not one for everybody 3) Performance consideration: seems so that Unity eats performance and batteries on laptops. Again, no value in service it provides in return. That's a known issues and high on the list of things to address this cycle 4) Search applications capability in Unity is really poorly designed and of limited usage. In some cases, you almost have to know exact name so that application you are searching for could be found. In others searching application itself has confusing, complex user interface. This could have been done much better. Suggestions on how to improve are welcome. The search capability is not really poorly designed, it's rather than applications don't provide a lot of things to search for out of the menu title and description. The search feature does support keywords though and there are plans to increase their use starting this cycle, that should improve things quite a bit if most common applications define a solid set of keywords. Simplicity in user design, down-to-earth logic could guide designers to much better user experience with Ubuntu. You should like unity then, its simplicity is somebody most people who dislike it complain about ;-) -- Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Ayatana-dev] autolanding of unity and linked components branches ready and activated!
On 23/11/11 22:42, Didier Roche wrote: Le 23/11/2011 09:40, Olivier Tilloy a écrit : Hey Didier, That was a long e-mail, thanks for setting this up! On 2011-11-22, Didier Rochedidro...@ubuntu.com wrote: […] Limitations As we are running all projects in parallels to avoid having to wait too much before a branch from a project is merged, we need to have in mind that there is no dependency automagic check, like: 1. you add a new API to nux 2. you use this API in unity. 1. needs to be merged (and so built) successfully. Please, do not approve 2. until 1. status is merged. Then, the local repository in the pbuilder will automatically take the right Nux version with the additional API. If you set it to approved before the nux branch is merged, you can have great changes seeing your branch rejected because it will fail to build. Be patient before approving the second branch, as the merger is running every 15 minutes, you should get a merge soon. :-) Launchpad knows of a notion of Prerequisite Branch when creating a merge request, that is a branch that should be merged before the one under review for everything to work as expected. As far as I know this is not limited to branches targeting the same trunk, so you could very well make a branch of e.g. nux be a prerequisite to a branch of unity. Maybe there’s a way of instructing tarmac to respect those dependencies? Indeed, if people are setting those dependencies (which wasn't the case in the past), we can use that. I need to make some tests to ensure that we can set pre-requisite on branches that have no common revisions on different projects though. Prerequisite branches are not used for this case. I use the prerequisite branches as I often developed using bzr-pipelines. The way the prerequisite branch is used is primarily for diff generation. The prereq branch is merged into trunk, then the proposed branch is merged into the result, and the diff of that second merge is what is connected to the merge proposal. However, there is still an important check needed here. It is entire feasible to have a chain of dependent branches (I once had 13), where earlier branches are not approved, but later ones are. We shouldn't be able to land an approved branch if any of the prerequisite branches in the chain are not approved. We do need to make sure that we allow merged ones though, as the prereq stays even if it is merged. All that happens there is the merging of the prereq into trunk becomes a no-op for the diff generation. Tim -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
AW: Login and lock screen dialog should be the same
Just for my grasp: pre lightdm is 11.04 and earlier ? lightdm is since 11.10 ? -Ursprüngliche Nachricht- Von: Steffen Holanger [mailto:holanger.stef...@gmail.com] Gesendet: Mittwoch, 7. Dezember 2011 22:31 An: t...@prosts.info Betreff: Re: Login and lock screen dialog should be the same I see your point but at the same time I disagree. As I pointed out I think it is important to give Ubuntu a feel of being whole. If I am not mistaken the old login (pre lightdm) used to be the same as lock screen. I think this is important because Ubuntu would feel more professional and not like some OS just put together by random pieces. Making it possible to see if others are loged on or not in the lightDM login screen should not be a huge task/problem eighter. this could be done by eg. high lighting the user(s) that might be loged in already. An alternative might be to make it possible for users to choose between same login and lock screens or make them different. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Ayatana-dev] autolanding of unity and linked components branches ready and activated!
Hey Didier, That was a long e-mail, thanks for setting this up! On 2011-11-22, Didier Roche didro...@ubuntu.com wrote: […] Limitations As we are running all projects in parallels to avoid having to wait too much before a branch from a project is merged, we need to have in mind that there is no dependency automagic check, like: 1. you add a new API to nux 2. you use this API in unity. 1. needs to be merged (and so built) successfully. Please, do not approve 2. until 1. status is merged. Then, the local repository in the pbuilder will automatically take the right Nux version with the additional API. If you set it to approved before the nux branch is merged, you can have great changes seeing your branch rejected because it will fail to build. Be patient before approving the second branch, as the merger is running every 15 minutes, you should get a merge soon. :-) Launchpad knows of a notion of Prerequisite Branch when creating a merge request, that is a branch that should be merged before the one under review for everything to work as expected. As far as I know this is not limited to branches targeting the same trunk, so you could very well make a branch of e.g. nux be a prerequisite to a branch of unity. Maybe there’s a way of instructing tarmac to respect those dependencies? Future improvments I will add additional checks soon in the future: - ensure that every branches have at least a bug attached. There will be the possibility to add NOBUGNEEDED to bypass it, but we will have a report to avoid abuses (and that will enable us to have the bug automatically set and components added). No more unclosed bugs! Having real metrics of number of bugs closed, and such… - ensure that every branches have tests (with a test directory of file changes). There will be the possibility to add NOTESTNEEDED, with the same report to avoid abuses. - we can even ensuring that the contributor signed the CLA checking for the right team if the team is put up to date again on launchpad. - we can also imagining that after UIF or FF, if the bug linked to the branch authenticated as a UIFe or FFe is not acked by the release or documentation team, it is rejected automatically. - finally, we can get a ready to release time, where no approved branch are merged automatically, when set in this mode, we can directly choose which branch to merge and pick only those that are helping getting closer to the release (a freeze-like mode in some way). For developers, in a nutshell, no more direct merge, think to set the approved status in the merge request and all should be smoothed. Of course, as this has been tested on a test project in the infra, we are enabling projects one after another. In what order will the projects be enabled? How is this going to affect (if at all) unity-2d, which has had a partially similar set-up for quite some time now? Thanks, Olivier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Problem compiling libunity
Hey there, Sorry for sending this to so many mailing lists at once, but expertise in my problem area doesn't seem to be thin on the ground. I've got a problem compiling libunity in my C++ application which is proving to be quite the showstopper, specifically getting GCC to figure out there libdbusmenu-glib/client.h lives. All the details are included in the question I asked on Ask Ubuntuhttp://askubuntu.com/questions/92266/problem-linking-libunity and I was just wondering if someone experienced in such matters could take the time to head over there and check it out. I'd be most grateful if someone could please tell me what I'm doing wrong. Thanks, Chris -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
