Re: System compositor progress
On Wed, 2012-07-11 at 18:04 +1200, Robert Ancell wrote: Hi, We're now at the point where the system compositor [1] is starting to work. Any brave souls who want to start playing with this can have a look at the instructions in the blueprint. Obviously THIS IS HIGHLY EXPERIMENTAL, so play at your own risk! In saying that, early feedback is most welcome and anyone who wants to hack on this contact Chris (RAOF) and I and we can point you at code to play with. The PPA linked there will not work quite yet; it's missing a build of mesa (and then of weston xserver). This should be soon; just as soon as mesa actually builds :) I'll send a follow up mail for our intrepid system-compositites when it's all bedded down. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: System compositor progress
On Wed, 2012-07-11 at 18:04 +1200, Robert Ancell wrote: Hi, We're now at the point where the system compositor [1] is starting to work. Any brave souls who want to start playing with this can have a look at the instructions in the blueprint. Obviously THIS IS HIGHLY EXPERIMENTAL, so play at your own risk! In saying that, early feedback is most welcome and anyone who wants to hack on this contact Chris (RAOF) and I and we can point you at code to play with. This is now ready to roll, for intel, nouveau, and radeon. Intel is most tested, and should essentially work; nouveau and radeon are less tested. amd64 packages of weston are still publishing: you need at least 0.89.0~system-compositor4-0~raof3. Other than that, go to town! Chris -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop12.04-Topic] Handling Failure Gracefully
On Tue, 2011-10-25 at 09:56 -0400, Robert Ancell wrote: Late topic... In the real world there are always going to be failures, triggered by things like software bugs, hardware failures and misconfiguration. Ubuntu should where possible handle common failures and provide predictable feedback to the user that the system is broken. I think we have the intention that most of this should work already, but it would be good to check we've worked out the right failures to handle and to methodically test they all work in 12.10. Some common failure cases and what should happen: - Failure to start X server - Run failsafe X server - Failure to start any X server - Show error on text console - Failure to start greeter - Run X server with error message - Failure to start session - Return to greeter with error message - Failure of compiz/unity during session - restart compiz/unity - Failure to start application - show error message - ... Yes. This is an important aspect of system robustness that I don't think we've generally paid a lot of attention to. At the last UDS(?) Bryce and I got together with Colin Watson and discussed a subset of this problem - around what kernel options the GRUB recovery mode should set, and when recordfail (to automatically show the GRUB menu next boot) should be cleared. I'd be very interested in having a broader discussion about this. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Language Chooser at Login 3: The Choosening (or: Keyboard Selector)
Rovanion in #ubuntu-devel brought to me a problem that's related to the lack of language selector - we also don't have a keyboard selector. I don't think I've seen this discussed before, and I think it should be addressed. The problem description here is: You have a multi-user system with multiple keymaps. This could be dvorak/qwerty, or latin/cyrillic is apparently common. Different users can then have passwords using different keymaps, which means that unity-greeter needs to be able to understand this. Either unity-greeter would need to cache each user's keymap and automatically switch keymap for the password field, or use something like the keyboard indicator in the greeter. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Call for testing: LightDM
On Wed, 2011-06-08 at 11:01 +0200, Milan Bouchet-Valat wrote: Le mercredi 08 juin 2011 à 01:09 -0700, Bryce Harrington a écrit : Boiling Matt's post down this is what I'm reading: 1. NIH 2. It doesn't start a GNOME session 3. Doesn't have arbitrary shiny stuff like slidy effects 4. Auto-update when users are created or deleted 5. Accessibility functionality UI 6. Gratuitously drawing a clock 7. Handle power policy via gnome-power-manager rather than via upower #1 yeah but whatever. #2 seems like a feature unless proven otherwise. #3 who cares. #4 ok, fair point, seems minor though. #5 important, but I think already under development. #6 yeah right. #7 huh? As I see it, the problem is that when you'll have brought back accessibility, power and sound management, you'll essentially have started a GNOME session or an equivalent, losing a good part of the lightweight. Maybe I'm wrong, though - history will surely tell. I think there's a fundamental difference between “start a full GNOME session and blacklist stuff that in inappropriate for a login screen” and “start the bits of a full GNOME session that a login screen needs”. GDM apparently chooses the first route, which is why the recent security advisory where you could start a web-browser from the GDM screen with GDM's credentials can occur :). signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: gnome-panel as a fallback
On Mon, 2011-06-06 at 09:46 +0200, Didier Roche wrote: On lun., 2011-06-06 at 02:18 -0400, Eric Appleman wrote: Hi, I was wondering under which circumstances the GTK3 gnome-panel can be used as a fallback for Unity or GNOME-Shell. Hi Eric, We are trying to build a coherent environment for ubuntu and GNOME upstream experience. Consequently, the plan (and what's already in oneiric) is: * Unity and Unity-2d are installed on the CD, Unity-2d being the fallback of Unity. In addition, each one have a separate session in gdm (and probably will have in lightdm as well) to start them directly. Note that this will be the case for finale only if we can have the full unity-2d accessibility stack working in time. * gnome-shell and gnome-panel are available in the repository. gnome-panel can be installed separately from gnome-shell and each one have as well a separate session in gdm/ligthdm to start them directly. gnome-panel is the fallback of gnome-shell. (gnome-shell pulls gnome-panel). I'd like to know if Unity 2D will also be used for for FailsafeX sessions. Not sure about that one as different people means different things about FailsafeX sessions. if it's session without 3D acceleration, right, that's what is already the case in oneiric. FailsafeX as no driver has been able to be loaded/X can't start (bulletproof X), that's more a question for the Xorg guys :) My initial thought would be that FailsafeX should use whatever fallback would be otherwise used; Unity2D if Unity is the user's default, GNOME classic if Shell is the user's default. If Unity2D is unacceptably slow or likely to be broken with VESA then that should be revisited. IMO FailsafeX should give the user as comfortable experience as possible for them to try to work out what went wrong and fix it. That's likely to be the default fallback session. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] GTK3/GNOME3
On Fri, 2011-04-08 at 09:12 +1000, Robert Ancell wrote: On 04/07/2011 05:59 PM, Martin Pitt wrote: Hello all, kind of obvious topic, but next cycle we'll need to move to GTK3 and GNOME3. Aside from the obvious update the package versions, I see the following particular challenges: * Review our patches, and be rather aggressive about removing those which are intrusive and which we have carried for ages without upstream acceptance. Of course there are also still patches which we haven't even proposed upstream, these should be discussed in bugzilla.gnome.org. * Port pygtk2 apps to PyGI with GTK3. The biggest ones are ubiquity and software-center, but there is also quite a long tail of smaller upstream software. * Discuss GTK3 theming with UX/design. Our current murrine based Humanity theme doesn't work with GTK3. I expect that this will bind a lot of developer capacity next cycle, but at the same time it's very important that we do this to not lose track with GNOME. Martin One issue we need to tackle is the use of clutter. Applications are moving towards using clutter (e.g. cheese) and my experience with clutter has been: - Requires good 3D support - Has never seemed to work well for me... We need to work out early if we can have a hard dependency on clutter or not, and what happens if you can't run clutter applications. As discovered with enabling cairo's GL backend in bug #725434¹, if a lot of apps pick up dependencies on clutter it will have a non-trivial impact on memory usage on the nvidia binary drivers. Not much that we can do about it, but it's another thing to consider. [1]: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/725434 signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Call for Natty Feedback!
On Tue, 2011-03-01 at 13:51 -0800, Bryce Harrington wrote: On Tue, Mar 01, 2011 at 04:18:22PM -0500, Sean McNamara wrote: 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. Can you provide a bug # (with a full backtrace if possible)? I'm putting a priority on following up on xserver segfaults. (Actually there are no public X crash bugs open against natty at the moment, so I wonder that what you're seeing is not actually an xserver segfault. Regardless, it should be investigated.) 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. The first half of that could be unity's handling of multi-head, which I agree seems like it needs more QA. The second half, regarding blank spaces where the mouse gets lost, is a long standing known X.org issue (bug #389519). (There's been a patch proposed but it's not upstream yet.) There's a patch series for this and pointer barriers (which Unity might want to use, too, for the BDB + multihead) on the xorg-devel mailing list. The crtc-clamping works and if we really wanted it the patch is relatively safe and could be FFe'd. The pointer-barriers need protocol changes, and I'd be hesitant to include them before the protocol has been finalised. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: GNOME session saving dropped in natty
On Sat, 2011-01-22 at 03:09 -0500, Jacky Alcine wrote: On 01/21/2011 01:14 PM, Bryce Harrington wrote: On Fri, Jan 21, 2011 at 07:36:55AM -0800, Rick Spencer wrote: On Fri, 2011-01-21 at 16:16 +0100, Martin Pitt wrote: Vishnoo [2011-01-21 20:41 +0530]: Is there a bug filed for this, which we could follow? I don't think we should bother. Session saving can't ever be perfect. You won't ever get back things like your unsaved current documents, undo buffers, network connections (chat), etc, and those are much more interesting than the position of your windows (not that GNOME would or could ever get that right even). I think this has always been a half-baked misfeature. For proper session saving/restoring there is suspend and hibernate. Well, there is suspend. Hibernate does not exactly work perfectly for many peole. Nor does suspend... ;-) Is there a way of flashing the loaded applications in memory and all of those handles to disk and just loading it back? You've pretty much just described “hibernate”. When it works, that is ☺. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Maverick - Natty upgrade, unity, gnome-panel and windowmanager's party…
On Fri, 2010-11-26 at 11:22 +0100, Didier Roche wrote: On ven., 2010-11-26 at 10:10 +1100, Christopher James Halse Rogers wrote: On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote: Hey fellow desktopers, [snip] 2.2.2 So, we can think the other way around: only run gnome-panel when needed and not setting it as a required_components by default in the default sessions but still on the gnome classic session (this can be done as well as sessions adds some additional gconf paths). - 2.2.2.1 if unity runs, nothing to do, no flipping - 2.2.2.2 if unity can't run, we need to launch gnome-panel. That's currently done as a compiz plugin (and the code is executed even if opengl compiz can't be run on that hardware). So, we can launch gnome-panel, BUT there is no way to set it dynamically as a required component without making heavy changes to gnome-session: basically, what gnome-session doesn't launch, it doesn't know what it is, so we need some kind of libbamf library to match the .desktop file or whatever so that I can add to my yesterday hack a way to set it as a required_component dynamically. If you're already adding a dbus call to set required_component dynamically, can't you get gnome-session to also start that component when it's added as a required_component? Unfortunately not, because it has to match /Client and /Apps (if you look at d-feet, it should be obvious). However, if you launch gnome-panel from the command-line or from another process, it doesn't get an id (and every --sm-client-id doesn't seem to work) matching it to its desktop file, hence the fact we should use libbamf for it, but can be a little bit overkill :-). One idea from seb's after discussing on IRC will be to launch gnome-panel by gnome-session using a dbus call. That can works, just have to see how hard it is to hook this in gnome-session. Yeah, this is what I meant; have gnome-session start gnome-panel when you add gnome-panel as a required component. If Seb's already brought it up, good. Great minds think alike ;). signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Maverick - Natty upgrade, unity, gnome-panel and windowmanager's party…
On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote: Hey fellow desktopers, [snip] 2.2.2 So, we can think the other way around: only run gnome-panel when needed and not setting it as a required_components by default in the default sessions but still on the gnome classic session (this can be done as well as sessions adds some additional gconf paths). - 2.2.2.1 if unity runs, nothing to do, no flipping - 2.2.2.2 if unity can't run, we need to launch gnome-panel. That's currently done as a compiz plugin (and the code is executed even if opengl compiz can't be run on that hardware). So, we can launch gnome-panel, BUT there is no way to set it dynamically as a required component without making heavy changes to gnome-session: basically, what gnome-session doesn't launch, it doesn't know what it is, so we need some kind of libbamf library to match the .desktop file or whatever so that I can add to my yesterday hack a way to set it as a required_component dynamically. If you're already adding a dbus call to set required_component dynamically, can't you get gnome-session to also start that component when it's added as a required_component? signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Gthumb as default image viewer?
On Sun, 2010-03-14 at 21:42 +0200, Otto Kekäläinen wrote: su, 2010-03-07 kello 12:09 -0800, Rick Spencer kirjoitti: On Sun, 2010-03-07 at 12:06 -0800, Rick Spencer wrote: On Sun, 2010-03-07 at 21:02 +0200, Otto Kekäläinen wrote: The thread ended up in that F-Spots view one image in folder -mode should have basic editing capabilities included. Unfortunately in Lucid this does still not exist, and I really think that EOG should be replaced with GThumb to give users even the basic functions (that are even found in Windows XP). It's coming. Please review the work items. [..] https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps [raof] f-spot: provide save button and drop instant saving: DONE [raof] f-spot: provide undo in edit mode: TODO [raof] f-spot: provide next/prev buttons in view mode: TODO Thanks, I just tested it and it is definately an improvement. I'd still hope that the F-Spot edit mode would also contain functions to rotate images. There are rotate buttons in EOG, but it would be a better user experience to have all edit functions in one view (=the F-Spot edit view). There's the existing “straighten” tool, which allows for a small degree of rotation to make the horizon horizontal, and there are 90° rotation buttons - like in EOG - on the toolbar. You may not have the toolbar enabled, however, which means you'll also be missing the “undo” button. It might be a good idea to ignore the user's preferences and unconditionally enable the toolbar on startup in View mode. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Review of featured applications
On Fri, 2010-03-26 at 03:32 +, Shane Fagan wrote: On Fri, 2010-03-26 at 14:22 +1100, Robert Ancell wrote: On 26/03/10 14:05, Shane Fagan wrote: - Remove Eclipse - Huge download - Only supports Java out of the box - The Eclipse brand is strong enough that it doesn't need promoting Im going to go out on the limb and suggest we replace it with Monodevelop it supports mono,java,python,valaetc although require the user to install the support for each language. My review of all the supplied IDEs showed MonoDevelop to appear to be the easiest to use, but: - I've never used an IDE for any significant period of time - I didn't use any of the proposed IDEs to do more that write a hello world program. We need to consider what sort of user clicks on featured applications and which users would benefit from the suggested IDE. My experience of IDE users is: - They're generally passionate users who have a preferred IDE (much like text editors for non-IDE programmers). So by suggesting an IDE we're targeting people who haven't already chosen an IDE. - IDEs tend be a part of a developer package. If we suggest MonoDevelop will users link well to documentation and the developer community? Or will it just be a fancy text editor/compiler? Saying it in a simpler way: - Will an IDE encourage people to learn programming? - Will opportunistic developers be able to use it to complete their desired project? - Will experienced developers find the suggested IDE helpful or will they already use their existing IDE/do the research themselves? Well no it wouldnt encourage people to learn programming. Hmmm I dont think there is any good python IDE for the opportunistic developer. I dont think many experienced developers use IDEs too much. The ones I know in development companies use eclipse (or different flavors of eclipse) or text editors. I use netbeans in college but for python I use gedit. I think Python (and dynamic languages in general) are just really hard to do good IDEs for, for roughly the same reason that it's hard to do static fault analysis, at least in general. In some ways I think it's a semi-deliberate trade-off - python is much easier to write, but needs to *be* written. In the same way that python much easier to unittest, but needs to be unittested (more than languages with a static type system, compilers, etc). IDEs with decent code completion are a joy to work in. I'd be much less productive hacking on C# code in emacs than in MonoDevelop. signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
