Re: First release of geocode-glib available
On 05/14/2011 11:24 PM, Bastien Nocera wrote: The fact that we have only one implementation means that we have one well maintained implementation. I don't think it's much of a problem. Do you have particular reasons why you think that supporting multiple backends is actually useful? Availability of up-to-date street data is heavily dependent on the provider. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On Fri, 13.05.11 14:59, Robert Ancell (robert.anc...@gmail.com) wrote: I'm proposing LightDM [1] as a replacement for GDM. I started the proposal for this in GNOME 3.0 [2] but due to the young age of the project I thought it better to wait until 3.2 before making a full proposal. This is it. I apologise this has been done after the proposal period. Why replace GDM? - LightDM is a cross-platform solution. Ubuntu is planning to switch to it this cycle, and other distributions have expressed interest in the project. By sharing this piece of infrastructure GNOME can spend more time working on important GNOME components. I am pretty sure more platforms currently use GDM than use lightdm, how can you claim this as a reason that lightdm was better? In fact, what you claim here could be used as a good reason to convince Ubuntu to use GDM, since that is what the majority uses, not as a reason to convince the others to use lightdm, since that is only used by one relevant distro so far, Ubuntu? LightDM is aligned with freedesktop.org. What is this supposed to mean? - I am confident that the LightDM architecture is simpler than GDM. Some indicators of this: - Smaller code size - Well defined interface between greeter and session - Less dependencies - Less internal interfaces But do you support everything that gdm supports, too? Like all the a11y stuff? Or the fprint auth, the extensibility and stuff like that? - By having a well defined interface between the greeter and daemon, it is significantly easier to develop a greeter without knowledge of how display management works. This is useful as the skillset and motivations of these two sets of developers are different. But why is that a benefit? I think we want one good one, instead of a lot of bad ones? Modern forms of authentication, like the biometric stuff, or auth tokens usually need some kind of specific UI integration. Why do you think that it is in our interest to complicate that even further, by requiring that 10 greeters need to be updated for this, instead of just one? - LightDM is a platform for future work and is investigating the use of new technologies like Wayland. Hey, that's a non-issue. Grand plans don't count. The gdm devs can promise us Skynet integration and they could be as convincing with that as you are as with a promise of Wayland integration. In general I do believe it is completely OK to replace existing components with complete rewrites from time to time. I have pushed that through myself more than once. But if you do you better have your arguments ready for this. You must have a very good case. You must support everything the old software you are replacing can provide, or have very good reasons why you do not want to support specific features (I have not seen such a list from you). You must support a lot of new features. You must have made clear that you fully understood the problem, you must show that you tried to fix the existing component, or you must have a good reason why you think the current solution is so broken that there is no value in trying to fix it. You must be able to deal with criticism and respond to it. You must show that you can rethink the set of problems, and that you have a good idea where you want to go with this. You need a vision. Right now the only benefit I can see with lightdm is that it allows writing greeters in Qt more easily. I am not sure why that would be interesting to GNOME however. In fact I believe a goal of GNOME should be to head for stricter vertical integration of the platform, not to make balkanization even easier. I too believe the gdm source code is not as simple as it could be. But I think lightdm mostly trades features against simplicity here. And the features you drop are not crazy features that nobody will mind, they are core features, they are features we want and that took us a long time to get. In line with my work on systemd and related techs I have quite a number of things I'd like to see improved in gdm. For example, I want the login screen to show up during early boot. I want background auto-logins with foreground auth queries (i.e. what Alex already suggested here). I want automatic multi-seat. I want hotplug support. I want things to be more dynamic. I want more flexible auth mech support, I want stronger Ply integration. If want soft session switching. But lightdm does not offer any of this, and doesnt make anything of this easier to implement. In fact it puts us even further away from it. Progress might require rewriting components, but just rewriting things is not automatically progress. gdm might not be perfect software. But it is powerful software, and its problems can be fixed in an evolutionary, not a revolutionary way. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sat, 14.05.11 12:31, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Matthias, Dave, Matthias Clasen [2011-05-13 8:33 -0400]: * Language Selector, which allows you to configure your language and fallbacks ($LANGUAGE/$LC_MESSAGES), locale ($LANG), list of installed languages (packages which provide translations, dictionaries, OO.o help, etc.), and input method.This can probably be integrated into the now existing GNOME 3 module. Language selection is in the region panel, and the plan is indeed to have input method configuration integrated there as well. Unfortunately, we lack a person with the necessary skills and knowledge to really drive this, currently. Cooperation in this area would be highly appreciated. I am not quite happy about some parts of the current Ubuntu language selector UI, so we want to make some changes anyway. It got quite a bit more complex over the years due to user demands in some regions of the world (like separate LC_MESSAGES and LANG setting), as well as integration of extra package installation (language specific word lists, hyphenation patterns, spell check dicts, etc.). If at least some of these features are desired to have in upstream c-c, I'd be happy to discuss the design with Dave and/or c-c maintainers (not in this thread though, please) and then work on an implementation, and then we can provide the rest of it (like packaging integration) as an Ubuntu patch. If we stop having a separate package for this, I'm of course interested in keeping the latter relatively small. Just out of curiosity, what's the mechanism Ubuntu uses to forward user locale settings to the system? i.e. what's the path to make locale configuration system-wide with Ubuntu? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sat, 2011-05-14 at 12:31 +0200, Martin Pitt wrote: Hello Matthias, Dave, Matthias Clasen [2011-05-13 8:33 -0400]: * Language Selector, which allows you to configure your language and fallbacks ($LANGUAGE/$LC_MESSAGES), locale ($LANG), list of installed languages (packages which provide translations, dictionaries, OO.o help, etc.), and input method.This can probably be integrated into the now existing GNOME 3 module. Language selection is in the region panel, and the plan is indeed to have input method configuration integrated there as well. Unfortunately, we lack a person with the necessary skills and knowledge to really drive this, currently. Cooperation in this area would be highly appreciated. I am not quite happy about some parts of the current Ubuntu language selector UI, so we want to make some changes anyway. It got quite a bit more complex over the years due to user demands in some regions of the world (like separate LC_MESSAGES and LANG setting), as well as integration of extra package installation (language specific word lists, hyphenation patterns, spell check dicts, etc.). If at least some of these features are desired to have in upstream c-c, I'd be happy to discuss the design with Dave and/or c-c maintainers (not in this thread though, please) and then work on an implementation, and then we can provide the rest of it (like packaging integration) as an Ubuntu patch. If we stop having a separate package for this, I'm of course interested in keeping the latter relatively small. This is something we actually want, as per the mockups in https://live.gnome.org/Design/SystemSettings/RegionAndLanguage If you're interested in providing patches, see us on #control-center * system-config-printer: We decided to continue to use that instead of the GNOME 3 c-c one. s-c-p is a lot more complete and proven. Hmm; this is an example of the pick-and-match mindset that pits downstreams against upstreams. Can't we cooperate on making the printer panel good enough for everybody ? I don't see a reason why it wouldn't be technically possible. However, it will take quite some time until all the missing features will be added to the new GNOME printer applet, and unlike the locale selector I won't have time to help with this particular item; I guess this would be a question for Tim Waugh and Till Kamppeter. My gut feeling is that it is certainly technically possible and desirable, but will take some time, and until then we'd rather not break printing for everyone (we can switch over when it's ready). Please make sure you at least file bugs for those missing features. Marek is doing a lot of work on this, and it would be a shame to miss out on particular features just because nobody told bugzilla. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hey Lennart, Lennart Poettering [2011-05-15 18:26 +0200]: Just out of curiosity, what's the mechanism Ubuntu uses to forward user locale settings to the system? i.e. what's the path to make locale configuration system-wide with Ubuntu? Debian/Ubuntu store the system-wide default in /etc/default/locale. It is a plain source with /bin/sh style file like -- 8 - $ cat /etc/default/locale LANG=de_DE.UTF-8 LANGUAGE=en LC_MESSAGES=en_US.UTF-8 -- 8 - Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Colin: Your report missed the following bug, which is a better example of some of the more serious issues Canonical had working with upstream GDM: https://bugzilla.gnome.org/show_bug.cgi?id=587750 As you can see in the bug report, Robert was not provided with much real support or guidance about how to move forward even though Canonical made it clear on numerous occasions (on gdm-list and to the board) that this bug was of particular concern to Canonical and their users. Brian On 05/13/11 04:41 PM, Colin Walters wrote: On Fri, May 13, 2011 at 12:55 PM, Robert Ancellrobert.anc...@gmail.com wrote: There have been problems for years and years and years. There is some point where you need to reconsider if that strategy is appropriate. So here's some actual data: https://bugzilla.gnome.org/buglist.cgi?cf_gnome_target=---;cf_gnome_version=---;query_format=advanced;emaillongdesc1=1;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;bug_status=RESOLVED;bug_status=VERIFIED;email1=robert.ancell%40gmail.com;product=gdm;emailtype1=substring It looks like to your credit, you have submitted patches; some like https://bugzilla.gnome.org/show_bug.cgi?id=596831 have been accepted, others like https://bugzilla.gnome.org/show_bug.cgi?id=593996 discussed, considered, and rejected. The latter one is obsoleted now by the accounts service anyways. I'm not convinced by this data that GDM has been a problematic code base to work on. You're obviously free to create a new project; but on the basis above, I'd say you really didn't try very hard to make real changes in GDM before deciding to rewrite from scratch. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Bastien: On Fri, 2011-05-13 at 13:43 -0500, Brian Cameron wrote: GDM has evolved into a display manager that is most focused on tight integration with GNOME. This is perfect for GNOME users and distros that focus on GNOME users. However, GDM is not always a good choice for other desktop systems, distros that perhaps want to provide multiple desktop choices and be more desktop neutral about display management, or distros that need to support devices that may not support things light OpenGL. Since when did GDM require OpenGL? I must have missed the point when we started using gnome-shell in the login screen... Yes, you are right. GDM does not currently use OpenGL. My comment was meant to be understood as an example of how GDM may be moving in a direction that requires certain hardware or only works on certain operating systems. Sorry if I was not clear. For example, I also raised concerns that the GDM/ConsoleKit evolution may be moving in a Linux-focused direction. If GDM is evolving into a display manager with tight GNOME integration that works only with specific hardware and/or operating systems, then an alternative display manager may be needed by some users. It is not really clear what the future GDM/ConsoleKit plans are in this regards, and nobody seems to clarify. snip I think it is obviously important to Oracle to have display management options that are not too tightly bound to things that are not supported on Solaris like systemd, DeviceKit, PolicyKit, etc. Also, Oracle's Sun Ray products work best with a display manager that supports a non OpenGL GUI. I could imagine GDM becoming more tightly focused on OpenGL in the future, like GNOME Shell. Thus, perhaps LightDM could be considered a fallback display manager for the GNOME community. Again, I was just trying to highlight that some things that display managers need to do can be different across different distros. There is already code in upstream GDM to make it work well with Solaris RBAC instead of PolicyKit, for example. I'll repeat what I said in the past. Solaris developers will need to write some code at some point, or just give up. We can't stand around waiting for them to make a move when we want to better the functionality of GNOME as a Desktop. I have personally written committed over 100 patches to GDM since the 2.21 rewrite timeframe. Work I have done has improved GDM usability, XDMCP code, how GDM works when managing multiple displays at the same time, etc. Other Solaris developers have also helped, such as Halton Huo. This has bee time consuming since (as Jos pointed out), getting changes accepted into GDM can be very time consuming. So, developers working on Solaris have been supportive of the new GDM rewrite, I think. Your comment seems to be rather dismissive. Anyway, is there a real need or benefit to talk about Solaris GDM participation in a discussion about whether to accept LightDM as a module? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Thu, May 12, 2011 at 11:15:02PM +0100, Allan Day wrote: Sounds like it should be both a new feature and a part of GNOME core. It would be great to be able to introduce it as a feature in 3.2. I've started a feature page here [1]. [1] https://live.gnome.org/ThreePointOne/Features/FilePreviewing I'd like some (design) feedback about this. First of all, I didn't read the emails fully so I might be asking things that have been explained.. :) 1. Evince is supposed to be a generic document viewer. Is there any overlap with Sushi? 2. What about the file associations? You might want to easily view things, or actually work with the file (change it). How would this be handled? What would happen by default on a double click? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUPnP inclusion
On Sun, May 15, 2011 at 11:16 PM, Shaun McCance sha...@gnome.org wrote: Hi Zeeshan, Hi Shaun, Could you or another GUPnP developer work with me to create a page for it in the Platform Overview? I was doing that some weeks ago (actually your mail about that is in my inbox so i don't forget) but then this move of GUPnP process started and I decided to wait on that so I don't end-up putting links into out website that will break soon. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hello Lennart, Lennart Poettering [2011-05-15 21:10 +0200]: Sure, that I know, but what I was wondering is how the unprivileged user code that g-c-c is can make changes to this root-owned file. What is the machanism used here? Right, our language-selector has a polkitified D-BUS service for this purpose. For package installation it uses aptdaemon (a PackageKit-like D-BUS service for package installation which provides the necessary Debianism). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Let's try that again... On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: (Background: I am working on cleaning up all those little services that can change locale/clock/timezone/hostname/... in the context of systemd) In case you were not aware, in MeeGo 1.2 we've added a clock interface to connman. This mainly handles NTP client functionality but can also control (manually or automatically) the system timezone. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hi, On Sun, May 15, 2011 at 5:01 PM, Ross Burton r...@burtonini.com wrote: Let's try that again... On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: (Background: I am working on cleaning up all those little services that can change locale/clock/timezone/hostname/... in the context of systemd) In case you were not aware, in MeeGo 1.2 we've added a clock interface to connman. This mainly handles NTP client functionality but can also control (manually or automatically) the system timezone. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt If only you'd use the standard org.fd.DBus.Properties interface here then it would be a lot easier to use via e.g. GDBusProxy and other bindings. And it's a lot easier to inspect with tools like gdbus(1) or d-feet(1). Not saying it's impossible to write the code to get the properties and watch for changes - but it's something that _most_ people get wrong or they block the main thread or they end up with proxies where half the properties is from the old owner and the other half is from the new owner. Things like that. (I also see this is using an object exported at / - that's wrong too but it's a lot harder to get this point across to people.) /random_rant_no_need_to_follow_up David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sunday, 15 May 2011 at 22:14, David Zeuthen wrote: If only you'd use the standard org.fd.DBus.Properties interface here then it would be a lot easier to use via e.g. GDBusProxy and other bindings. And it's a lot easier to inspect with tools like gdbus(1) or d-feet(1). Not saying it's impossible to write the code to get the properties and watch for changes - but it's something that _most_ people get wrong or they block the main thread or they end up with proxies where half the properties is from the old owner and the other half is from the new owner. Things like that. (I also see this is using an object exported at / - that's wrong too but it's a lot harder to get this point across to people.) /random_rant_no_need_to_follow_up I'll follow up anyway :) with yes, I know, but you'll have to tell Marcel. Just the messenger etc. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Sun, May 15, 2011 at 2:30 PM, Brian Cameron brian.came...@oracle.com wrote: Yes, you are right. GDM does not currently use OpenGL. My comment was meant to be understood as an example of how GDM may be moving in a direction that requires certain hardware or only works on certain operating systems. Sorry if I was not clear. For example, I also raised concerns that the GDM/ConsoleKit evolution may be moving in a Linux-focused direction. So to be concrete (for clairty to those following along that don't already know). Oracle ships a product called SunRay. It's a thin client system where the individual thin clients are treated as black box hardware devices that speak the X protocol. Some of these devices don't support certain X extensions GNOME rely on like RENDER and GLX. I think this is what Brian is alluding to (Brian, correct me if i'm wrong on any of the above). If GDM is evolving into a display manager with tight GNOME integration that works only with specific hardware and/or operating systems, then an alternative display manager may be needed by some users. Of course, that's fine. I don't think many would disagree with that. When developing your platform for SunRay, you've got to make choices that are appropriate for the technology you have. And it may be LightDM is the way to go for that product. Certainly, getting LightDM vetted through the ARC review process would be a good thing for it. SunRay is proprietary, though, and so kind of sits outside the focus of GNOME. But we've talked about this before, and I think we both agreed (right?) the choices you make for that platform may sometimes be orthogonal to and contrary with the choices we make together for GNOME. We all have several hats to wear and juggle I guess. It is not really clear what the future GDM/ConsoleKit plans are in this regards, and nobody seems to clarify. Clearly, GDM should try to stay as closely aligned with the direction of GNOME as possible. Certainly that means gaining a GNOME 3 look and feel, and using the bits of the GNOME 3 library stack that make sense to use, etc. Anyway, is there a real need or benefit to talk about Solaris GDM participation in a discussion about whether to accept LightDM as a module? Right, this is straying a bit off the original topic. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Sun, May 15, 2011 at 1:58 PM, Brian Cameron brian.came...@oracle.com wrote: Your report missed the following bug, which is a better example of some of the more serious issues Canonical had working with upstream GDM: https://bugzilla.gnome.org/show_bug.cgi?id=587750 As you can see in the bug report, Robert was not provided with much real support or guidance about how to move forward As far as I know, every time no gdmsetup has been brought up the response has always been more or less that GDM shouldn't act like a bolted on app with its own setup UI. Instead, the various bits of configuration that are supported should be exposed in an integrated fashion with the rest of GNOME. That means putting some stuff in the (at the time unwritten but planned and frequently discussed) accounts dialog, relying on system default values for certain things, and potentially adding Make default buttons to places in control-center. I know you and I personally discussed this at various points (and seemingly came to consensus on). I'm pretty sure Robert and I discussed it (but could be I'm misremembering and it was Martin or Sebastien I talked too, not 100% sure). Jon also sort of mentioned it on the bug report you point at above. Anyway, we can't all agree on every change. We have to evaluate each one on a case-by-case basis and do what's right for the project as a whole. I think on the whole, though, GDM does a pretty good job at what it's supposed to do, has a pretty good track record. It totally could be that this particular bug is the reason is Robert wrote LightDM. I don't know. I don't know the history there at all. I guess it doesn't *really* matter though. It's fine he's writing LightDM! I wish him the best for that project. I'm sure that project has its place and its own intrinsic value. I just don't think its place is in GNOME right now. We have something in that place already, and it's serving its role well enough. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sun, 15.05.11 22:50, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Lennart, Heya, Lennart Poettering [2011-05-15 21:10 +0200]: Sure, that I know, but what I was wondering is how the unprivileged user code that g-c-c is can make changes to this root-owned file. What is the machanism used here? Right, our language-selector has a polkitified D-BUS service for this purpose. For package installation it uses aptdaemon (a PackageKit-like D-BUS service for package installation which provides the necessary Debianism). Ah, thanks a lot! That's what I was wondering about. Next question: can you point me to some sources? (or alternatively some project name I could google for?) Would like to have a look on it, before I spend time on this. Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sun, 15.05.11 22:01, Ross Burton (r...@burtonini.com) wrote: Let's try that again... On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: (Background: I am working on cleaning up all those little services that can change locale/clock/timezone/hostname/... in the context of systemd) In case you were not aware, in MeeGo 1.2 we've added a clock interface to connman. This mainly handles NTP client functionality but can also control (manually or automatically) the system timezone. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt Ah, very interesting. This is good to know. Interesting place though, in connman. Hmm, do you happen to know where connman stores the high-level timezone name? i.e. Europe/Berlin? We'd like to standardize some place for this in the systemd context, and I am currently figuring out if we can just adopt an existing solution. Thanks a lot, Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On Sun, May 15, 2011 at 01:30:56PM -0500, Brian Cameron wrote: Yes, you are right. GDM does not currently use OpenGL. My comment was meant to be understood as an example of how GDM may be moving in a direction that requires certain hardware or only works on certain operating systems. Sorry if I was not clear. For example, I also raised concerns that the GDM/ConsoleKit evolution may be moving in a Linux-focused direction. If GDM is evolving into a display manager with tight GNOME integration that works only with specific hardware and/or operating systems, then an alternative display manager may be needed by some users. It is not really clear what the future GDM/ConsoleKit plans are in this regards, and nobody seems to clarify. At least as far as OpenGL goes, it's looking fairly likely that the llvmpipe rasteriser in mesa will be capable of handling the necessary level of performance and functionality such that it's practical to use OpenGL effects without hardware 3D. This obviously only handles the case where the system running the display is under our control and can have its GL renderer replaced. If we're talking about systems where the display protocol is fixed and the thin clients can't easily have their rendering architecture reworked, we'd still be throwing a lot of pixels around. My strictly personal viewpoint is that GLX has been standardised for a very long time and developers really should be able to expect that it exists, but I appreciate that real world concerns may make this more of a constraint. -- Matthew Garrett | mj...@srcf.ucam.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
