Re: [PROPOSAL] GNOME Goal for 3.8: No more Python 2
On Tue, 2012-07-03 at 10:13 -0400, Joanmarie Diggs wrote: On 07/03/2012 05:04 AM, Bastien Nocera wrote: On Tue, 2012-07-03 at 09:23 +0200, Olav Vitters wrote: On Mon, Jun 25, 2012 at 09:44:52AM -0400, Joanmarie Diggs wrote: As per earlier discussions, I am proposing that we target GNOME 3.8 as our first all Python 3 release. Total lack of responses + 3.8 is far away: IMO ok. Most likely because people don't know what's required. What's the contingency plan? Will we be able to ship 2 version of Python, 2 versions of the bindings and have old and new apps work as expected? What's needed for plugins? Speaking as someone who did the Python 3 conversion for both Orca and Accerciser (code review pending), what I learned in the process is that there are many things which are both Python 2 and Python 3 compatible. In fact, the bulk of the changes are because quite a bit got backported into Python 2. Mind you, those things which did get backported are definitely in Python 2.7, might or might not be in Python 2.6, probably are not in 2.5 Thus if everyone can start with the changes which are both Python 2.7 and Python 3 compatible, our contingency plan could be a minimum required version of Python 2.7. FWIW, I've found this library to be extremely helpful when maintaining .py code for the common subset of the 2.x and 3.* dialects: http://pypi.python.org/pypi/six/ It may be worth thinking about blessing this as a dependency. Hope this is helpful Dave ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Tue, 2008-07-01 at 17:51 +0200, Pavel Rojtberg wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro[EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. I dont think the point is that moot. Being one of the beginner developers you refer to, I can say that autotools are really daunting. As is that most of Gnome Modules are written in C. Up to now I tried write some patches, but always capitulated because of some autotools and/ or C weirdness. And honestly I dont see why I have to learn that freaking tools, when there is Scons/ Python which are beginner friendly and which I personally use for my own projects. So my contributions this far were limited to the parts of gnome written in python. Rereading, this has turned into a rant, but posting in the hope that it will be useful: It often puts me off, as an experienced C developer. When I first started looking at GNOME (and indeed Linux) I was an experienced C developer, having worked on various commercial videogames, finding ways to save a few hundred bytes here and there to get stuff to fit in RAM on the target platform... and I still have trouble with the GNU autotools: I want to spend my brainpower thinking about the problem domain of the program, my users, and my code, not having to deal with a pile of hacks upon hacks for
Re: Composition [was Re: gnome-session proposal]
On Thu, 2008-06-26 at 23:02 +0100, Iain * wrote: On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: Nah, one thing about a compositor is that it keeps off-screen copies of all the windows so it does not have to invalidate regions when the stacking order changes. To be totally honest, I've never really thought of that as being all that important. I don't think I've ever thought You know, I wish that window would redraw faster when I've restacked it but maybe thats just me. If a compositor just kept off screen copies of windows, and didn't have live previews etc etc, would you honestly use it? Yes - it's great when running an app remotely, using X forwarding with ssh, avoids having to send all the redraws across the internet. Probably are better ways to do this, but it's a godsend for me when I need to. Hope this helps Dave ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:02 -0500, Federico Mena Quintero wrote: On Wed, 2006-07-19 at 11:17 +0100, Bill Haneman wrote: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html The Testing guide is really nice, because it's essentially a checklist that you can run through your application. Bill, do you know if any of the points in there could be automatically checked with LDTP or some other ATK-based automation suite? Keyboard bindings are queryable via ATK, so you can do some of the testing automatically, but I think ultimately you need a human to do part of this: you'll only see stuff via ATK if it's already at least somewhat accessible. I believe many of the specific test cases are automatable, for example KEY__001: You could automatically inject keyboard events to simulate tabbing through the UI, and look at the XY extents of the widgets, and flag bogus tab orderings that way. Accessibility will definitely be one of the things required to attain the highest certification level for GNOME apps. I hope that (especially) governments will look for this high mark of certification. Federico ___ 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: System Monitor Graph Style Suggestions
On Tue, 2006-02-14 at 20:54 -0400, Steven Garrity wrote: Taking a quick look at the Gnome System Monitor today, it occurred to me that the graphs have a distinct EGA-graphics-circa-1986 visual feel to them. These graphs are ripe for some Tufte-fication [1]. On the subject of Tufte and gnome-system-monitor, I've implemented a GtkCellRenderer subclass for sparklines and implemented it for the per-process CPU usage: http://bugzilla.gnome.org/show_bug.cgi?id=319682 Here's a quick mockup of the dialog with some suggested color (and only color) changes: http://actsofvolition.com/images/screenshots/gnome/system-monitor-mockup.png In the hopes of keeping potential implementation simple, I have only changed is the background color, grid color, and changed the default user-configurable colors to some I picked quickly from the HIG [2]. Of course, smoother lines would be nice too... Going slightly beyond the above, both X and Y axis ought to be labelled, probably with a simple 100% at the top of the Y axis, and perhaps minutes on the axis axis. (an unlabelled axis is one of Tufte's peeves) Going much beyond, who is the intended user of gnome-system-monitor, and what is its purpose? Is it simply a GTK replacement for top, or is it intended to show something that's meaningful to: - end-users? - sysadmins? - software developers? (I don't think that top is particularly good for any of the above) My primary use of sparklines is when I'm wondering why my CPU spiked 10 seconds ago and I only just got control back over the UI (by which time the constantly shifting CPU stats aren't helpful - what if the process isn't around anymore?) [snip] Hope this helps Dave ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing gobby?
On Wed, 2005-11-16 at 17:51 +, Gustavo J. A. M. Carneiro wrote: Qua, 2005-11-16 às 18:23 +0100, Philipp Kern escreveu: On Nov 16, 2005, at 15:53, Gustavo J. A. M. Carneiro wrote: [snip] Sure. I know it's only 0.3.0. Maybe that means Gobby needs 6 more moths to improve the protocol. That's perfectly fine and doesn't mean it is any less a great program. It's just that we need to cope with some users that, erm, let's say are not very smart :P Our users _are_ smart [1]; they're just not knowledgeable about the internals of how a particular technology works, and the ways in which it's counter-intuitive to their experiences in the rest of their lives. [snip] Dave (who both loves Gobby and is paranoid about security) [1]: hey, they chose to use our software, right? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Enable accessibility by default in development releases?
Currently, a11y is not enabled by default in GNOME, as it has a performance cost (CPU and memory usage). But that means that there's a huge amount of code that isn't being exercised by most testers and developers. So here's a (possibly crazy) suggestion: during development releases, enable a11y by default, and during stable releases, disable it by default. That way people running jhbuild, GARNOME etc would be running all of the a11y code, and any bugs in that layer would be discovered more quickly. As I understand it, the GConf key: /desktop/gnome/interface/accessibility determines whether a11y is on. The schema for this key is provided by the libgnome tarball; here's a link to the schema file in CVS (hopefully not too mangled): http://cvs.gnome.org/viewcvs/libgnome/schemas/desktop_gnome_interface.schemas.in?view=markup How sane would it be to link that schema.in file so that the key's default is true for an odd-numbered release and false for an even-numbered release? Or to set this up with a boolean in the configure.in? Or simply to change it back and forward manually? (since maybe we'd want to disable it by default again in the last development release before a stable release, in case we've broken the off case) Is this crazy? Been tried before? Thoughts? Dave trying to undo all the good work on performance-list Malcolm ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Some notes on LDTP and Dogtail
I just noticed this criticism of me on Nagappan's blog [1]; copied inline here: DogTail ideas copied from LDTP !!! Do you believe ? One of the main Dogtail Author Dave Malcolm was interacting with me in person in GUADEC 2005. He collected all the details from me !!! and in Boston submit, I came to know that Dogtail has been released. When I checked the list of authors Dave Malcolm was one among them and most of the CVS commits in dogtail project was done by him. In GUADEC 2005, I requested Dave to get some RedHat QA engineers to involve in LDTP project, he assured me that he will try his level best. So, I assumed that he will try to get somebody for :LDTP, Actually what happened is totally reverse. Dave tried copying the ideas from LDTP and gave it as DogTail ;) I'm sorry to have to post this to desktop-devel-list but I don't blog and I think it might be worth a detailed public explanation of the LDTP/Dogtail situation as I see it. We've been looking at automated testing for the whole time I've been at Red Hat (since well before LDTP's original announcement). The framework developed by LDTP isn't the first Free/Open Source testing framework, and it isn't the first one to leverage the excellent a11y layer available in GNOME [2]. Thanks to everyone who's worked on the a11y layer, especially everyone at Sun. When LDTP first was announced, we were excited, and looked at it. Unfortunately, we quickly concluded that the framework they had implemented was unsalvageable. It was (i) a large chunk of C code (why C??!!! - Python, C#, Java - anything but C, please, I have too many large chunks of C code in my life already) that (ii) implemented application maps, as the sole way of communicating with applications: application maps are a legacy of the approach used by automation tools in the Microsoft Windows environment, where you don't have the rich metadata about the GUI available. It's a big complex unnecessary thing that the scriptwriter has to keep up-to-date. It's never up-to-date, and your scripts break regularly for various reasons. (iii) It used a totally custom system for driving tests - why not use a real scripting language? As far as we could see, once you've eliminated the extraneous elements like the application maps, there wasn't anything of use in the project, so we continued to work on our own internal system. At this point, we could have approached the LDTP project and said that we admire the spirit of their project but want to totally reimplement it from scratch. In retrospect, maybe we should have done. I wonder what their response would have been; from my experience in the open source software world I wouldn't have expected them to go for it. The LDTP framework went through a number of releases. We continued to build our own system, and observe theirs. Nagappan and the rest of the LDTP team have done a good job of improving their framework: for example, creating a Python wrapper that removes objection (iii) above. In the process the LDTP team has uncovered a number of a11y bugs. This is valuable work, and kudos to the LDTP team for doing this: this has been of use to the Evolution project, for example. However I think that in spite of their good work in this area the framework has enough deep flaws (mostly (ii) above, but partly (i) as well), sufficiently so that, given a blank slate today I'd be doing a rewrite from scratch, rather than trying to fix the framework. I attended GUADEC 2005, and was in a difficult situation: our framework was at the time an internal project by Red Hat's Quality Assurance team, and I can't talk about internal projects. I did my best in my questions and interaction with Nagappan to raise my concerns with LDTP's technical approach: the usage of application maps, and the usage of C. I went back to the QA team within Red Hat and tried to come up with a way forward. The approach we settled for was to open-source Dogtail, and make it available to the various open source communities: GNOME, mozilla, OpenOffice.org etc - and to our competitors. Right now I'm half-wishing we hadn't open-sourced it. Looking at it from a cynical business standpoint, I think Dogtail gives Red Hat a significant competitive advantage over companies who are trying to use LDTP to automate their regression testing. But ultimately I want GNOME, the Mozilla Project, OpenOffice.org and friends to have some tools to help get good releases out of the door, and I'm glad we open-sourced our framework. Some possible ways forward: I have the beginnings of an emulation layer written that fakes the LDTP framework, taking the interface exposed by the Python bindings and reimplementing it on top of Dogtail (which leverages the various quality-of-life-for-scriptwriter things that Dogtail adds to the mix: automatic highly-readable logging, the robustness of the search algorithm, the avoidance of hard-coded sleeps, etc). I've been concentrating on improving Dogtail
