Weekly Edition
Return to the Development page
| |||||||||||||||||||
A GNOME 3.0 plan
During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing official, and it could actually have been considered as some friends talking together about things they deeply care about. There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision. Slowly, a plan started to emerge. It evolved, changed, was trimmed a bit, made more solid. We started discussing with a few more people, got more feedback. And then, at GUADEC, the Release Team proposed an initial plan to the community that would lead the project to GNOME 3.0. Quite some time passed; actually, too much time passed because too many people were busy with other things. But it's never too late to do the right thing, so let's really be serious about GNOME 3.0 now! Let's first diverge a bit and discuss the general impression that GNOME is lacking a vision. If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue. What we are missing is people blessing one specific vision and making it official, giving goals to the community so we can all work together in the same direction. In the pre-2.x days, the community accepted as a whole one specific vision, and such an explicit blessing wasn't needed. But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we "just" have to be the voice of the community. (As a sidenote, the roadmap process [1] that we tried to re-establish two years ago was a first attempt to fix this. Unfortunately, it turned out that we were missing the most important side of things: a project-wide roadmap. This is because a collection of individual roadmaps isn't enough to create a project-wide roadmap.) So let's go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on: - Revamp our User Experience - Streamlining of the Platform - Promotion of GNOME There are also other potential areas that are worth exploring if there is enough interest from the community. From a release management perspective, there are various questions that are raised in the GNOME 3.0 context. We definitely need a plan to organize the development (see below for details on it), but we might also want to take this opportunity to rethink how we ship GNOME: are the module sets still the best way to deliver GNOME? There is no obvious answer to this, but the way we will present GNOME in the future will certainly have an impact on this. Revamp our User Experience ============================ When talking with some great people at GUADEC about GNOME 3.0, one concern that came more than once was that it would be an error to do GNOME 3.0 without any big user-visible change. While some of us didn't necessarily agree with this concern, it was still a fairly valid one. But it turns out that if you tell the community that there's something after 2.x, then the community will stop vaguely thinking about future ideas and start working on concrete plans. It seems pretty clear now that there are two important ideas that can have a real positive impact on the user experience: - GNOME Shell [2]: the shell idea is not just about changing the panel and the window manager. It's about changing the way you start an activity and how you switch between two different activities. Or more generally, how you manage your different activities on the desktop. - Changing the way we access documents (via a journal, like GNOME Zeitgeist [3]): having to deal with a filesystem in their daily work is not what makes users happy -- on the contrary, they generally just want to access their documents and not to browse their hard disk. Providing new solutions to this problem (using timelines, tags, bookmarks, etc.) is something that has been of interest in our community for a long time, but we never completely jumped in. We simply should. These two ideas can form the basis of an overhauled GNOME user experience; they are not the only changes that we can and will do, but they definitely are the most advanced projects to help us move forward in terms of user experience. The GNOME Shell and the GNOME Zeitgeist projects are indeed already well underway, with working code and strong development going on for nearly six months. This means the effort is not about starting those projects, but about first completing them so that people can work daily with them, and then polishing them. There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. Streamlining of the Platform ============================ Since GNOME 2.0 was released in 2002, there have been quite some changes in our developer platform: new APIs have landed and some other APIs have been deprecated. There are even some platform libraries that are now nearly unused. This just creates some confusion and does not make the life of developers easy. Since we want applications to be developed for GNOME, this is an issue that we should fix. Hence, it makes perfect sense to rework our platform and try to clarify it for newcomers. Here are some steps that should be considered: - move all of the deprecated libraries out of the platform, so people stop using them in new code; - create a staging area in the platform for libraries that aim to be in our platform but do not offer enough guarantees at the moment (like GStreamer): this will send a clear message on what should be used; - include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain). - rework the way we present the platform to also integrate some of the external dependencies: while, say, D-Bus or Avahi are external dependencies, they are definitely what we want developers to use. And it's easy to be more explicit about this. - move the bindings closer to the platform when we talk about bindings, to make them even more visible and attract developers from all languages. The work that has been done on GObject introspection [4] will also deeply change the way GNOME development can be done; we've already started to see how it can be leveraged in GNOME Shell, and the fact that it can bring new popular languages like Javascript to GNOME is a huge benefit. All this has of course an impact on our applications: we will have to port the code away from all deprecated APIs, but also prepare our applications to be ready for forthcoming changes, like GTK+ 3.0. This is luckily a task that we can easily quantify and the progress can be tracked on a simple web page. Promotion of GNOME ================== Our community has historically been strong on the development side, but we have always struggled to promote GNOME. That's because this is certainly no easy task. Our user base has however grown significantly since our project started, and we failed to recruit people that could have helped here. GNOME 3.0 is an opportunity to change this and attract contributors that can help forge the communication around the GNOME project. The promotion of the project is definitely part of what makes a good release, and the Marketing Team can contribute a lot to the success of 3.0. Of course, an obvious goal for the promotion of GNOME in this context would be preparing the 3.0 release and the messaging around this release. After highlighting the changes done specifically for 3.0, one other immediate idea is to simply show the progress the GNOME project has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0 when compared to 2.0, and the same goes for 2.20. This could serve as a basis for work on explaining why our evolutionary approach in development works well. One common issue that often came up when discussing how to promote GNOME was that promoting the desktop as a whole is difficult. But there's no need to do that. We can instead focus our messaging around the GNOME experience: the basic GNOME experience simply is the GNOME Shell; but users actually do not use just the basic desktop, and they use applications. We've never explained why the applications developed for GNOME are good; we've never really put those applications under the spotlight. For instance, why shouldn't we put on the front page of the GNOME website a clearly labeled message about a good music manager? We wouldn't have to choose between Rhythmbox or Banshee: we can promote both, since both are good in different ways, and both are good examples of the GNOME experience. This leads us to a third item: relaunch our website. While our current website is known for being broken in various different ways from a communication point of view, we've not been able to deliver the new version that would fix things. Fixing the website is a large task, but we should not give up on this: the GNOME website is a core part of the GNOME identity, and we cannot ignore the current issues. This happened because of lack of manpower, but the good news is that there are web developers that are fond of GNOME and just don't know they can help the project. And the fact that web developers can play an important role is also valid for all of our users. As of now, we are not really empowering users to promote GNOME: what should a user do if he wanted to do so? We all know how some viral communication can benefit a project like ours, so the solution is simple: let's give ourselves a chance to make this happen! Other Potential Areas ===================== The areas presented above are actually not a big surprise to anybody following the GNOME development and are fairly obvious choices. However there are other candidates that would help make GNOME 3.0 a success. Those potential focus areas simply need people to step up so we can be sure expectations can be met. - Desktop Testing [5]: with the recent creation of the Desktop Testing Team, this topic becomes more and more visible. We can innovate there, and we actually should: we helped show the way in the free software world when it comes to usability and accessibility, and there is no reason for us not aiming at a similar experience for desktop testing. - Art: a GTK+ Theming API hackfest was held in February, where some good consensus was reached on how theming should be done in the future. This gives us a new opportunity for an updated look and feel. This can happen with the help from artists: if we have artists and coders working together, with the coders knowing the needs from artists, then there is no doubt that the result will simply rock. - People: the telepathy framework has nicely progressed over the last few years and it's offering great perspectives to integrate instant messaging, and more generally, interaction with people in other applications. With some focus, it could contribute to make GNOME a social desktop where you do not only work on documents, but where you also really interact with your friends. - Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24, and it helped make our presence in the mobile world visible. A lot of the changes that are planned around the platform are of direct interest to the Mobile Team. Organizing the Development ========================== We need to define a clear timeline for the development, with a schedule that will let us check that the development is on the right path. The end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30 release. This makes sense for various reasons: from a technical perspective, the timing is good for the integration of new technologies or projects (GNOME Shell, for example); from a messaging point of view, the evolution from 2.30 to 3.0 is logical and easy to understand. It's worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's actually quite surprising to see that we have still kept a 2.x version numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0 version is of course still an ambitious goal, but we can achieve it thanks to what we learnt in the past. The development methods we have adopted during GNOME 2.x are overall good methods and the community has become used to them. For example, contributors understand the reasons behind the freezes we have and try their best to respect those freezes. This is not something that should be changed because we now have an opportunity to try something else; on the contrary, those methods will make our path to 3.0 easier. Some regressions were pointed out during the past few cycles: those should not be ignored and we believe part of the reasons why they happened is that only a subpart of our community was trying to move forward, which created some controversy; having a community-wide focus should limit those controversies, and hence the regressions as felt by the community. The six months cycle is now part of our culture and has an impact on the free software ecosystem, with distributions basing their schedule on our schedule. Trying to change this crucial element of our release management, which works quite well, would certainly not help us in any way. Therefore, we will keep six months-based schedules. But having project-wide and long-term goals require some adaptation. GNOME 2.28 will not be an independent release or a destination in itself, but it will be a logical step towards GNOME 2.30, and therefore GNOME 3.0. Of course, we should be prepared to consider the fact that GNOME 2.30 might not be good enough for us to call it 3.0. All of our time-based releases are also quality-based releases: if the QA Team feels a release should be delayed, then it will be delayed. In the context of 3.0, this is something that we should be ready to diagnose early on during the 2.29 development cycle and we should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example. That being said, we want the community to try as hard as possible to make "GNOME 2.30 = GNOME 3.0" a success. On a more general note, overlaying a long-term development cycle (3 years for example) with project-wide goals, on top of our six months development schedules is something we want to keep after GNOME 3.0. Conclusion ========== You can already check out the schedule for the 2.27 and 2.29 development cycles [6]: it contains some concrete steps and deadlines that will help keep our work focused to make GNOME 3.0 a reality. As already mentioned, this is an ambitious plan and it will only be realized if everybody comes out and helps. Companies can contribute a lot -- for instance, the GNOME Shell effort is doing great thanks to Red Hat's involvement. But GNOME wouldn't even exist without all of the volunteers who are passionate about the project. It's because this passion is so strong that we can build such a plan! We're getting there. We strongly believe that all this can make a good plan for GNOME. Sure, it's not perfect. And there will be disagreements and issues along the road. But it is the way forward. The GNOME Release Team, [1] http://live.gnome.org/RoadMap/Process [2] http://live.gnome.org/GnomeShell [3] http://live.gnome.org/GnomeZeitgeist [4] http://live.gnome.org/GObjectIntrospection [5] http://live.gnome.org/DesktopTesting [6] http://live.gnome.org/TwoPointTwentyseven -- Les gens heureux ne sont pas pressés. -- devel-announce-list mailing list devel-announce-list@gnome.org http://mail.gnome.org/mailman/listinfo/devel-announce-list (Log in to post comments)
A GNOME 3.0 plan Posted Apr 2, 2009 14:38 UTC (Thu) by drag (subscriber, #31333) [Link]
Well good luck.
I like the idea of the 'GnomeShell' quite a bit, but have never been really all that excited about the 'Social Desktop' metaphore. I guess I tend to be quite a bit more conservative about depending on third party network services. But each person has different needs and such.
Oh, in the Gnome shell consider some way to group applications to their own virtual desktop. In OS X each application gets it's own layer on the desktop with the menu bar always located in a consistant spot on their desktop. This has many advantages over the clutter that you tend to get with the MS Windows-style desktop. Linux has already had virtual desktops, but they tend to be confusing to new users and application windows tend to get lost in the jumble.. the OS X style is much more intuative.
Before with X Windows this would of been impossible to do correctly, but with Compiz and it's ability to do multiple layers (if you have a widget layer, why not have a dozen layers?). So instead of a 'spinning cube' or 'virtual desktop wall' concept you would have a 'layers of transparent pages' concept. So that while you have unfettered access to all the application windows of the current application your working in you always have easy visual reference and single-click access to other applications without depending on the alt-tab, click-drag, or pager applet features.
Even if it is not possible to group application windows in that manner, I still think it would be a very clever way to expand the usable desktop space through the use of virtual desktops and whatnot.
A GNOME 3.0 plan Posted Apr 6, 2009 3:29 UTC (Mon) by luya (subscriber, #50741) [Link]
I think Gnome seems to be inspired by Sugar Interface hence "Social Desktop"
A GNOME 3.0 plan Posted Apr 2, 2009 14:47 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
What about reducing memory requirements a bit? Not as sexy, but it might still make people happy.
A GNOME 3.0 plan Posted Apr 2, 2009 21:02 UTC (Thu) by ovitters (subscriber, #27950) [Link]
You really only suggest this? And call that 3.0? I think you misunderstand the purpose of this document.
Anyway, reducing memory usage is done in every GNOME release. It wasn't included in the final release notes, but as just one example, pango uses 8MB less memory with certain fonts. There are various other examples.
Further, seems you missed out on the part where we'd remove usage of the deprecated libraries. When those are all removed, memory usage will automatically drop (as those libraries won't be loaded anymore).
A GNOME 3.0 plan Posted Apr 3, 2009 6:42 UTC (Fri) by job (guest, #670) [Link]
How about reducing memory usage to one tenth?
It should be realistic but a real challenge which would involve a lot of the underlying libraries. Just like the fast boot the Intel guys did.
As an example, my terminal is right now 30M rss and the yellow sticky notes is 40M. I understand this includes a number of non-trivial things, unicode libraries and whatnot, but it should be possible. This would enable a whole range of new uses.
A GNOME 3.0 plan Posted Apr 4, 2009 8:26 UTC (Sat) by oblio (guest, #33465) [Link]
http://www.joelonsoftware.com/items/2007/09/18.html
"As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and roll band, and in either case, your program would run faster. Assembler programmers dont have groupies."
Make stuff that works (aka stable), and make stuff that does things (aka has lots of functionality). Memory usage decrease - important, though hardly crucial for a major release, IMO.
A GNOME 3.0 plan Posted Apr 4, 2009 11:13 UTC (Sat) by nix (subscriber, #2304) [Link]
Note the past tense. It is still sort of true for memory consumption, but
even there reducing memory consumption (or, rather, short-to-medium-term working set) can increase speed, 'cos caches aren't anywhere near as large as RAM.
It is no longer true for CPU consumption. For non-parallelizable code
A GNOME 3.0 plan Posted Apr 4, 2009 13:29 UTC (Sat) by oblio (guest, #33465) [Link]
Even if it's parallelizable, you have all sorts of single core embedded CPUs, in which case it isn't true either. So I get your point.
But something like making a whole major release whose primary goal is to reduce the memory consumption of Gnome to 10% is prone to leaving Gnome in the dust bin of desktop history - you only have so much resources, and when you try this kind of optimization it becomes all you do, you can't really add features.
A GNOME 3.0 plan Posted Apr 5, 2009 19:50 UTC (Sun) by job (guest, #670) [Link]
First, I'm not sure someone who worked at Microsoft for three years writing about software methodology is an authority on this (as they never really succeeded in the embedded space compared to the amount of work and money spent). Second, even if Moore holds here as you describe that still gives you roughly five years for an order of magnitude increase. Don't you think a five year head start on your competitors is valuable?
A GNOME 3.0 plan Posted Apr 7, 2009 8:24 UTC (Tue) by oblio (guest, #33465) [Link]
"First, I'm not sure someone who worked at Microsoft for three years writing about software methodology is an authority on this (as they never really succeeded in the embedded space compared to the amount of work and money spent)."
What does Microsoft success in the embedded market (or lack thereof) have to do with the moral authority of someone writing about this topic? Logical fallacy in there :)
"Second, even if Moore holds here as you describe that still gives you roughly five years for an order of magnitude increase. Don't you think a five year head start on your competitors is valuable?"
It is valuable. But you only have so many resources. Do you really believe that you can go on an optimization spree, reducing Gnome to 10% of its current memory consumption, and still add features? Work on Vala, Zeitgeist, Gnome shell, stability improvements, Evolution Exchange backend, API changes, refactoring, deprecation of libraries, and still make everything 10x smaller? I highly doubt it that you can do it and ship before those 5 years are over. Therefore you win no time :)
A GNOME 3.0 plan Posted Apr 7, 2009 9:00 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Sounds like a nice Summer of Code task :)
A GNOME 3.0 plan Posted Apr 3, 2009 6:46 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
I didn't say that that should be the only focus of 3.0. But resource usage is far too often forgotten in the euphoria surrounding cooler new features, although it is important for many people. Free desktops used to be marketed as a way of letting people keep on using their old systems.
A GNOME 3.0 plan Posted Apr 2, 2009 15:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
How about porting GNOME under QT? :)
It will at last unite Linux desktop.
A GNOME 3.0 plan Posted Apr 2, 2009 15:42 UTC (Thu) by awalton (subscriber, #57713) [Link]
April Fools was yesterday.
A GNOME 3.0 plan Posted Apr 5, 2009 19:07 UTC (Sun) by petegn (guest, #847) [Link]
>April Fools was yesterday.
Ya could of fooled me i think it is an excellent idea GTK does nowt but cause hassle a switch to Qt would be one of the few sensible things that gnome could do
A GNOME 3.0 plan Posted Apr 2, 2009 15:49 UTC (Thu) by qg6te2 (guest, #52587) [Link] Moving wholesale to QT may not be the best idea. It's a nice toolkit in many ways, but it also feels like it's pretending to be an operating system. A more useful question for Gnome would be the wider adoption of C++. While it can be argued that C++ presents a somewhat larger barrier to entry than C, the payoffs in terms of increased productivity cannot be underestimated. Speaking from personal experience, moving from coding directly with GTK+ to using the gtkmm wrapper was an eye opener. Our code shrunk by a factor of two, while also becoming more readable.
A GNOME 3.0 plan Posted Apr 2, 2009 16:09 UTC (Thu) by drag (subscriber, #31333) [Link]
Well, like you pointed out, you can already do C++ in Gnome in the form of GTKmm bindings.
While C++ is not a 'official' language for Gnome it does end up getting used in a lot of Gnome-related stuff. Abiword, I am told, does C++ and is part of Gnome Office.
The 'official', or maybe better called 'Tier 1', languages for Gnome right now, as in the stuff that Gnome ships with by default, are going to be C, Python, and C#. Then there is a Gnome-specific language being created called Vala.
Of course bindings for other languages are avialable, like Java or Ruby.
The advantage to maintaining the low-level stuff in Gnome as C is that, well, C is can be made to be very fast and thus work is on the low level in terms of optimization and memory usage will extend greatly and affect all Gnome applications (so it is time well spent compared to the typical time spent on full sized C-only applications). Maybe more importantly, it is (relatively) easy to use C to create bindings for most other popular languages. It is still possible to do it for C++, but I think (in my very limited experience) that it is not nearly as nice especially during the compalation process. The third possible benefit to sticking with C is that your dealing with a mature code base with lots of years worth of bug chasing and optimizations.
Feel free to disagree, of course. It's not like I am a expert on the subject. This is all just a impression I get.
A GNOME 3.0 plan Posted Apr 2, 2009 17:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
QT is now actually _faster_ than GTK and eats less memory. And Vala and C# are just another ways to leak memory.
A GNOME 3.0 plan Posted Apr 2, 2009 19:12 UTC (Thu) by drag (subscriber, #31333) [Link]
> QT is now actually _faster_ than GTK and eats less memory.
Really? Got numbers? I keep people saying this and they have lots of nice micro benchmarks and whatnot.. but I never really seen a fair comparision of memory usage under real-world situations. (and no fair including applications like Firefox or OO.org.. they are not Gnome apps.)
Anyways (assuming that is true) just because QT is faster then GTK does not mean that GTK rewritten in C++ is going to be faster then GTK written in C.
A GNOME 3.0 plan Posted Apr 2, 2009 19:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Real world usage...
Well, for example QT Creator launches in less than a second on my computer (from a hot cache) and is very snappy. Anjuta on the other hand, works noticibly slower.
As for microbenchmarks - compare QT tesselator which supports OpenGL and software-only Cairo.
Of course, it's possible to write large projects in C. But in case of GNOME they are now just re-inventing the wheel, trying to create objective language on top of C.
A GNOME 3.0 plan Posted Apr 2, 2009 19:38 UTC (Thu) by nix (subscriber, #2304) [Link]
I far prefer Qt to Gtk, but even so your arguments are specious.
Your 'benchmark' is two entirely different applications, so the speed differences could be (and probably are) due to implementation differences completely unrelated to the choice of toolkit.
And your microbenchmark compares something that uses OpenGL (thus hardware
A GNOME 3.0 plan Posted Apr 2, 2009 20:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, it's hard to find a real-world comparison for QT and GTK. I just gave one example of a QT program which works fast enough.
"And your microbenchmark compares something that uses OpenGL (thus hardware
That's not the point of my argument. QT can use accelerated OpenGL tesselation (it can draw complex curves and polygons with hardware acceleration), but Cairo can't do it. Architecture of QT right now is simply much better.
For example: http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-...
"Again, unrelated to
Cairo is not a part of GTK, but GTK uses it draw majority of widgets
A GNOME 3.0 plan Posted Apr 2, 2009 21:25 UTC (Thu) by drag (subscriber, #31333) [Link]
But anyways saying "x application starts up in one second" and "y takes 30 seconds" is completely and utterly useless. It is just so worthless it is not even worth the time it takes for me to type this. Well, just barely.
Well not any more.
Well anyways. What I am saying is that you take a pure Gnome or Pure GTK desktop and have it perform X number of tasks and run for X number of minutes.. record the statistics, then do the same thing with KDE. It isn't that difficult, but any time I see it done it is never really conclusive. I've seen benchmarks comparing XFCE vs KDE vs Gnome and depending on the user's requirements XFCE used several dozen less megs of RAM to several dozen more megs of RAM compared to KDE or Gnome doing the same tasks.
Then after you compare KDE and Gnome you can then go onto explain why LXDE kicks the ever living crap out of both in terms of speed and resource usage and yet still uses GTK.
What does seem conclusive is the amount of features you have the amount of resources that is used up increases. It does not matter what language your using. The more the software does the more it is going to use up doing that.
In fact the benefits of C++ over C for the sake of having a object oriented language is so dubious at this point it's just silly getting into these language wars. C++ was written in C. There is nothing at all that you can do in C++ that you cannot do just as effectively in C. Saying otherwise is just rubbish. Any good programmer is perfectly and 100% capable of writing programs in a pure object oriented manner using C language.
The _REAL_ difference, then, between the two languages then is the amount of time and effort that you save in using C++ over C.
So that is the metric that you really need to look into. If your starting a new program then that is something that you should look into in a huge way, I mean it would be silly to start a new project in C if you needed a usable product in the foreseeable future if you thought that C++ was more efficient language.
Seeing how GTK exists in C right now, and it is already written, then I don't really see the benefit in rewriting it for the sake of using C++. Your not saving any time, your not saving any effort. In fact it would require a huge amount of effort, and years before you would even get back to the same level that you are already at.
Look at what happenned to KDE4. It has been almost FOUR YEARS since the last major KDE3 revision, 3.5... and yet KDE4 is still not up to were that was in 2005, in terms of usability and feature set. (and I am not talking about QT or KDE lib feature set, like plasma or whatever, I am talking about actually regular folks using software on it and getting work done). This was just a significant ABI/API change, not a complete rewrite or language change or anything like that.
The way things stand now is that GTK is established, it's compatible with all it's applications, it has lots of good language bindings so that people can use a multitude of different languages.
I can accept a change and getting rid of depreciated interfaces and thus abandoning compatibility with applications that have not been updated for years and years in a effort to improve usability and performance, but really I just don't see the benefit in what you guys are saying.
A GNOME 3.0 plan Posted Apr 3, 2009 4:36 UTC (Fri) by qg6te2 (guest, #52587) [Link] There is nothing at all that you can do in C++ that you cannot do just as effectively in C. Saying otherwise is just rubbish. Any good programmer is perfectly and 100% capable of writing programs in a pure object oriented manner using C language.Using the same logic one could argue that "there is nothing at all you can do in C that you can't do in assembler", including having an object oriented approach. There is a multitude of reasons why C++ exists, one of them being that much of the drudgery of handling objects is taken care of by the compiler.
There is ONE exception Posted Apr 3, 2009 6:01 UTC (Fri) by khim (subscriber, #9252) [Link] Using the same logic one could argue that "there is nothing at all you can do in C that you can't do in assembler", including having an object oriented approach. Unfortunatelly it's not true at all. Yes, you can implement OOP in assembler (heck, TASM 3.0 included a lot of OOP-oriented constructs), but in the end the acholess heel of assembler is the fact that you can not write portable program in assembler. You even may need to call functions differently under different OS with the same CPU! Thus C makes sense as "high-level-portable-assembler". There is a multitude of reasons why C++ exists, one of them being that much of the drudgery of handling objects is taken care of by the compiler. Unfortunatelly it only means you must fight the compiler tooth and nail to make it produce somewhat sane code. Take a look on this and compare it with the same things in sane languages (Java or even GObject - even if it's not language it's must easier to make it do what you want and not what it wants).
There is ONE exception Posted Apr 3, 2009 6:16 UTC (Fri) by qg6te2 (guest, #52587) [Link] Unfortunatelly it only means you must fight the compiler tooth and nail to make it produce somewhat sane code. Take a look on this and compare it with the same things in sane languages (Java or even GObject - even if it's not language it's must easier to make it do what you want and not what it wants).I'm not sure about "fighting the compiler tooth and nail". If one does that, it generally means one is fighting against the language rather than using it properly. Any language can be abused, and C++ is no exception. Furthermore, the link provided above leads to much Qt-specific code, which shouldn't be equated with all of C++ code. Qt has far more specific idiosyncrasies than gtkmm, for example.
There is ONE exception Posted Apr 3, 2009 13:06 UTC (Fri) by nix (subscriber, #2304) [Link]
Actually, most of the stuff in that link is about not violating the
compiler's invariants regarding class definitions that change. As this is technically a violation of the One Definition Rule in the C++ Standard, it's unsurprising that it's a bit of a nest of snakes... but you come across *exactly the same problem in C* if you have a system that makes heavy use of structures and you want to change some of them without recompiling all their users. The rules just *look* odder because the structures are automatically built for you by the compiler: if you had to build them by hand, *all the same issues would arise anyway*.
There is ONE exception Posted Apr 3, 2009 15:07 UTC (Fri) by cybernytrix (guest, #5727) [Link]
If you see how QT throws away almost everything C++ provides and it reinvents all these:
1. Why do you need MOC? Debugging is a royal pain! 2. Why doesnt it use C++ strings? 3. Why do you need to implement introspection? Isnt C++ "high level" to provide this. 4. STL??? So on... GTK and GObject arguably does the same. What is the point of using C++ when your toolkit simply does not use many language features and invents a whole lot of crap? Qt is a fine library and now it is even licensed as LGPL. The only feature of C++ they seem to be actively using is automatic calling of destructors and exceptions. Why bother with C++ for just these?
There is ONE exception Posted Apr 3, 2009 15:24 UTC (Fri) by boudewijn (subscriber, #14185) [Link]
1) No, actually not. Debugging is painless -- at least, that's my experience over the past ten years.
2) Because they aren't half as poweful as QStrings. 3) No, C++ isn't highlevel enough. 4) All Qt container classes are compatible with the STL.
And about the features of C++ Qt uses... Well, that was just silly hyperbole, right, not an honest
A GNOME 3.0 plan Posted Apr 3, 2009 14:39 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Plans to release GTK sometime next year are complete fantasies. It's also going to take several years (remember GTK1 -> GTK2 migration). In this aspect it won't be much different from QT3 -> QT4 migration.
I'll even make a prediction: by the time GNOME3 is released, it will be in the process of being abandoned in favor of KDE.
KDE4 was not just a significant ABI/API change, it was a major rewrite of most of parts of software. KDE 4.2 is fairly feature-complete now, with lots of new features compared to KDE 3.5.10.
On the other hand, you can count on GNOME to remove few features just to be "less confusing" to user.
A GNOME 3.0 plan Posted Apr 3, 2009 21:53 UTC (Fri) by drag (subscriber, #31333) [Link]
A. Gnome 3.0 is not going to be a nearly as significant of a change as GTK1 to GTK2 or from KDE3/QT3 to KDE4/QT4. It'll be a revamp of some UI features and depreciation of old features in a effort to remove dependencies and improve performance.
B.If QT is good and it is using C++ then what is the point to having two QTs? Why not just use KDE instead of Gnome? Why not just get rid of Gnome altogether if you think it should be all C++ or that it should be QT.. you already have everything you want, right?
A GNOME 3.0 plan Posted Apr 4, 2009 18:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
A) It's better be significant or GNOME is going to lose to Windows 7 and KDE4.
B) I would just throw out all GTK code right now If I could. But of course, there's just too much legacy code in GTK. So it's better to provide a clean migration path from GTK to QT.
A GNOME 3.0 plan Posted Apr 5, 2009 3:58 UTC (Sun) by Ze (guest, #54182) [Link]
>>B.If QT is good and it is using C++ then what is the point to having two QTs? Why not just use KDE instead of Gnome? Why not just get rid of Gnome altogether if you think it should be all C++ or that it should be QT.. you already have everything you want, right?
How about because QT is nearly as hacky as GTK+? Some of us would like a nice C++ library that uses standard libraries (or boost) and not some Hack that relies on Macro's and throws away type safety.
A GNOME 3.0 plan Posted Apr 5, 2009 3:50 UTC (Sun) by Ze (guest, #54182) [Link]
>>Seeing how GTK exists in C right now, and it is already written, then I don't really see the benefit in rewriting it for the sake of using C++. Your not saving any time, your not saving any effort. In fact it would require a huge amount of effort, and years before you would even get back to the same level that you are already at.
Yes it'd be more work to rewrite the library than to use the existing one but that is always true. The whole point is that GTK+ is a horrible hack to write object oriented code in it. It takes far longer than using gtkmm and that is only slightly less ugly.
The fact is that c shouldn't be the implementation language ,it should be just another binding.
Ideally we'd end up with a C++ as the implementation language with bindings for other languages and GTK+ v2 compatibability library.
C as OO Posted Apr 5, 2009 6:20 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
While it's true that writing OO code longhand in C might take up more characters than the same program written in C++, most of the time we spend coding isn't spent typing. The difference is immaterial. Personally, I'd prefer C++, but there's something to be said for writing in the linga franca, C.
C as OO Posted Apr 6, 2009 1:07 UTC (Mon) by Ze (guest, #54182) [Link]
>>While it's true that writing OO code longhand in C might take up more characters than the same program written in C++, most of the time we spend coding isn't spent typing. The difference is immaterial. Personally, I'd prefer C++, but there's something to be said for writing in the linga franca, C.
It's got a lot more to do than just the typing. It's all the type safety and general model. GObject is a PITA and deserves to die a quick death (to save the rest of us poor souls from using it).
A GNOME 3.0 plan Posted Apr 5, 2009 10:36 UTC (Sun) by oak (subscriber, #2786) [Link]
> Well, for example QT Creator launches in less than a second on my
computer (from a hot cache) and is very snappy. Anjuta on the other hand, works noticibly slower.
Without any info about your test setup, this comment is completely
[1] Many distros setup KDE to force some horrible Qt theme on Gtk. I.e.
> As for microbenchmarks - compare QT tesselator which supports OpenGL and
Cairo uses Xrender which can also be HW accelerated (due to complexity of
Cairo and GL also have different targets. Cairo aims for re-producible
A GNOME 3.0 plan Posted Apr 5, 2009 12:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
QT Creator does not depend on any KDE software. It's completely self-contained. It used GTK theme which is the default theme on QT 4.5 when running in GNOME environment.
Of course, Anjuta was launched from a hot cache too, without any heavy background processes, etc.
X Server uses proprietary NVidia drivers, but I don't think it makes any difference. I've just retried it with NV driver (no acceleration at all) and there's no difference.
Cairo can use XRender (and OpenGL for that matter) only for compositing, it can't accelerate tesselation and curve drawing. QT also can use slower software renderer if you want quality.
A GNOME 3.0 plan Posted Apr 2, 2009 19:17 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
That's some unsubstantiated FUD if I've ever seen it.
A GNOME 3.0 plan Posted Apr 5, 2009 7:45 UTC (Sun) by jengelh (subscriber, #33263) [Link]
The effort of moving from gtk to gtkmm, I would catiously say, is as big as having moved to any other C++ toolkit (± a few per-toolkit subtleties).
I pray wxWidgets, because I can switch underlying toolkits as I like (currently it seems like just a recompilation of the end-user program away). Now if there was a wxQt, you would get world domination as a bonus. I wonder whether anything will be done in that direction, because GNOME left a bad mark when Linus flamed it years ago for the interface doctrine.
A GNOME 3.0 plan Posted Apr 3, 2009 1:15 UTC (Fri) by bojan (subscriber, #14302) [Link]
Looks pretty good to me. I've been running a single top panel in Gnome for years (because I hate racing up and down with the mouse), so this Gnome Shell business seems very natural. Overlay mode (which, at first glance, looked like XP menu; it sure made me cringe until I _actually_ looked closer), looks very nice and logical. Top marks boys and girls!
The screenshots I'm referring to are here: http://live.gnome.org/GnomeShell/Screenshots
|
|||||||||||||||||||