Propose your module for GNOME now
Module proposal period for the next GNOME release has started!
If you are a maintainer of a module that you want to propose for official inclusion in GNOME: Do it now! See the wiki for the guidelines. Also note that you will receive slightly less negative feedback if you avoid using deprecated modules (libbonobo/ui, libgnome/ui, libgnomecanvas, libart_lpgl, gnome-vfs, libgnomeprint/ui, esound, orbit, libglade) and deprecated Glib and GTK+ symbols. ;-)
And now another (last?) GNOME 3 status update before 2.28 will hit the streets…
See also the cleanup stats and the 2.27/2.29 schedule.
Killing Bonobo
If I got everything right I could create the following categories for the GNOME modules that still depend on Bonobo/Orbit:
- A11Y
This seems to cover orca, dasher, gok, mousetweaks, accerciser and gnome-session. At-spi, gnome-mag and gnome-speech might die and get replaced by at-spi2, gnome-shell and speech-dispatcher. libgail-gnome has already died by getting integrated into gtk+ (Orca was the last consumer and got fixed two weeks ago).
See here for a general overview. - gnome-panel
gnome-panel blocks the Bonobo dependencies of bug-buddy, gnome-applets, seahorse-plugins, pessulus, sabayon, gdm, and empathy. It is likely that gnome-panel will get replaced by gnome-shell for GNOME 3 (but there is no final decision yet). - Evolution, Evolution-Data-Server, Evolution-Exchange
Evolution and friends just branched for GNOME 2.28.x so the kill-bonobo and dbus-hybrid branches now can get merged into (unstable) master. After that it will be a bit easier to see how much work is left. - gconf
Probably very ugly to fix. dconf might be quite ready (but developers a bit too silent in communicating that). Crossing fingers for a status report. It could also make sense to switch to the gconf-dbus branch in the meantime. - Legacy
- gnome-python-desktop (as a binding)
- glade3 (as a tool to create applications)
- Other modules that are not officially part of GNOME
Wondering about atomix, balsa, ghex, gnumeric, gossip and gthumb.
Bug reports are mostly filed (yes, we also do care about warning the maintainers of modules that use deprecated functionality and are not officially part of GNOME despite of sometimes unfriendly “I don’t care about your GNOME3 stuff, why did you file this at all?” answers).
Planner has a patch awaiting review/commit.
Killing deprecated GTK+/Glib symbols
- gnome-games currently looks worst. It depends on the release of a new ggz tarball now that ggz patches have landed.
- metacity seems to be in need of more love – patches welcome which might be partially shared with mutter.
- gedit is a bit reluctant to get in the patches too early because it would change UI behaviour. Understandable.
Killing libglade
The aim for August 24 is to have less than 10 modules still depending on libglade. Currently we still have 16 modules left (only very few of them blocked by the gnome-druid migration that has to happen first). If you want to help you should provide a patch. Here’s a how-to.
Killing libgnome and libgnomeui
Apart from the bindings there are not many applications left (yelp, gnome-control-center and gok got ported in the last days), but we all know that the last steps are always the hardest ones, right?
- libgnome:
evolution, tomboy, gconf (just removing an unused file). - libgnomeui:
evolution, evolution-exchange, gnome-panel, gnome-shell.
A gnome-shell release
A fresh and cool tarball is now available.
Killing libgnomecanvas
Evolution heavily depends on libgnomecanvas. It is highly unlikely that this code will be rewritten for GNOME 3 so libgnomecanvas can either be kept deprecated but shipped in GNOME 3, or Evolution copies the code to its internal codebase. Note though that libgnomecanvas itself heavily depends on libart_lgpl which is also deprecated.
GSeal
A rather unknown variable in the current equation as GTK+ does not have everything in place yet, hence it is currently still a moving target. See the wiki for more information and how to compile your module with the GSEAL macro. Maintainers are highly encouraged to try.
In general curious about the GTK+ status with regard to version 3. Hope to see an update about this next week.
Personal opinions on interesting modules
Modules that interest me and that could be interesting for GNOME 3 or later in alphabetic order and without any claim for completeness are:
dconf, gnome-do, gnome-global-menu, gnome-packagekit, gnome-scan, gnome-shell, tracker, vala, zeitgeist.
Just wanted to write this down somewhere as I tend to empty my brain on a weekly basis.
I always thought bonobo was supposed to be like OLE in windows, does anyone actually bother with compound documents any more… if so how would it work for gnome ?
If we assume gnome-shell is getting in, gnome-global-menu and gnome-do (at least) would require significant work on both sides to have good integration.
For example, the existing application launching features of gnome-shell really conflict with gnome-do, and gnome-global-menu is a panel applet (would it have to be completely rewritten in JavaScript to work in gnome-shell?).
I use both gnome-global-menu (buggy but convenient) and gnome-do (fantastic however you use it). Between the two I have a much sleeker desktop lately, and gnome-do’s docky interface has made a surprising impact on window management across multiple desktops. Recommend folks try gnome-do 0.8.2.
@Stu: Not sure if I got your question. General answer: “Use D-Bus, drop Bonobo.”
+1 for global-menu which increases the usability of GNOME magnitudes of what GNOME Shell ever will be…
http://dl.getdropbox.com/u/963697/Screenshot.png
@Sandy, @Tom: According to its website gnome-globalmenu is Gnome-Shell-ready:
http://code.google.com/p/gnome2-globalmenu/wiki/ReleaseNotes#Fully_Compatible_with_Gnome-Shell,_ready_for_a_possible_inclusio
I guess it will have to rearrange some of the items in the Gnome Shell panel, because by default Gnome Shell places for example the clock in the middle.
@Tom: It’s up to maintainers to propose their modules, plus it’s up to the community and the release-tean to discuss and accept them.
I know that it’s normal that many people have many different ideas which path a big software project should take for the next major version though. :-)
Thanks, but that doesn’t really matter to me since I won’t use Gnome-Shell…
And you’re free to.
@aklapper: Am I? So far I was under the impression that Gnome-Shell is a non-optional component of Gnome 3?
@aklapper: problem is that D-Bus is okay for IPC but doesn’t allow (AFAIK) components as Bonobo (or KParts in the KDE world) does.
@Alexandre Franke
Isn’t GtkSocket / GtkPlug what you mean?
http://library.gnome.org/devel/gtk/unstable/GtkSocket.html
@Tom: You did read this blog post, right? :-) “It is likely that gnome-panel will get replaced by gnome-shell for GNOME 3”. It’s not definite, but it is likely. So if it’s the case you are free to not use it by continuing to use GNOME 2 or by switching to another desktop environment.
@Alexandre Franke
http://ftp.moblin.org/moblin/releases/test/alpha1/doc/dbus/dbus-faq.html#components
“If you combine an IPC system with a set of GUI control interfaces, then you can have an out-of-process or dynamically-loaded GUI control.”
@Tom Today you can use GNOME without a panel, without nautilus, without metacity. Similarly, you can avoid gnome-shell, mutter, and friends. Your alternatives may not be actively developed or maintained anymore, though I would guess that certain Linux distributors will do *some* maintenance until they are comfortable shipping gnome-shell by default.
@gantenbein: it would be hard for me to argue as I’m no specialist of the topic but I once talked to a KDE dev who told me that we have no equivalent to their KParts and Chris Lord seems to agree (comment 10 on http://tieguy.org/blog/2007/05/25/choice-usually-sucks-documenting-choice-sucks-more-though/ ).
There **must** be a requirement set that users will be able to switch either one of gnome-global-menu, gnome-do, gnome-panel+nautilus and oh well, gnome-shell. There is no technical argument that prevents this from being possible and making gnome-shell a non-optional component.
Then people who really want can play with their gnome-shell while I am all fine without it…
@FunkyM: Why a requirement? As Sandy already wrote, GNOME does work without gnome-panel or whatever you want. If there is something that does not work for you clearly name it. But it’s not the main task of developers to remain compatibility with every ancient outdated technology out there – they have better things to do.
Again: Nobody forces you to use gnome-shell. Please do read the comments first – this has been explained already. Thanks. :)
About GSEAL GnomeGoal:
I’m making some patches to support it and I have to say that GTK+ developers are working on implement new accesor functions in the latest GTK+ versions.
As I said in the wiki page, the main problems (for my personal experience) are the accesor to allocation and to widget flags.
Now, there is already a getter for allocation (will land in 2.17.7) (see http://bugzilla.gnome.org/show_bug.cgi?id=585211 ) and a lot of functions for flags have been added (see http://bugzilla.gnome.org/show_bug.cgi?id=69872) (Thank you bratsche and mitch! ;))
Regards and keep the good work! :)
@aklapper: “As Sandy already wrote, GNOME does work without gnome-panel or whatever you want.”
I was not talking about the present situation at all.
“It’s not definite, but it is likely. So if it’s the case you are free to not use it by continuing to use GNOME 2 or by switching to another desktop environment.”
So basically you are saying (and which kind of forms as the religion around gnome-shell): If you want a different shell/desktop metaphor, please go away from GNOME. No choice.
“But it’s not the main task of developers to remain compatibility with every ancient outdated technology out there – they have better things to do.”
So everything which is not compatible with gnome-shell will be “ancient outdated technology”.
Again, I kind of hardly grasp how after those lines you can say that there will be any “choice”.
No need to comment more on that, just adding my 2 cents.
@FunkyM
1) GNOME is more than a window manager and shell. Changing out those components is not a huge deal. The “please go away from GNOME” comment is not really fair.
2) If you have problems with gnome-shell, perhaps you could provide specific feedback in the appropriate venues. Email desktop-devel-list, or write a blog, or do something to share your thoughts. Your current attitude is more like “I’m taking my toys and going home”.
If you feel like your needs as a user are not being met, then you need to provide feedback or nobody is going to even have a chance to address your concerns.
Realistically, upstream GNOME is only going to have the resources to support one window manager shell thing. Right now the momentum favors gnome-shell. Sure, we design our software so that you can swap these components without too much trouble, but if you have strong feelings about what should happen in upstream GNOME, please help! :-)
@FunkyM: Choices already exist and they will continue to exist as the code is free. If *all* the choices you prefer will still be maintained is a different question as resources are not unlimited. Probably also depends on the companies involved in GNOME. Of course you are more than welcome to constructively help by raising concrete issues you currently see.
By “ancient outdated technology” I refered to gnome-panel using Bonobo. You can help by coming up with patches, e.g. providing a D-Bus compatibility library, if you want to have gnome-panel in GNOME 3.
> The “please go away from GNOME” comment is not really fair.
To quote alklapper:
[…] you are free to not use it by continuing to use GNOME 2 or by switching to another desktop environment.
> If you have problems with gnome-shell, perhaps you could provide
> specific feedback in the appropriate venues.
Gnome-Shell is based on a ridiculous stupid idea. The only way to improve it is to completely ditch it. I wonder how well this will resonate with the mailing list. What the Gnome-Shell people basically are saying is that we are all idiots and that they are smarter than everyone else at Microsoft and Apple for the last 25 years. I don’t really expect to reason with people who have this kind of delusional attitude.
@Tom
Apologies, I missed the context on the “please go away from GNOME”. Thanks for correcting me. I still stand by the rest of my response. :-)
As for your gnome-shell comments, you should understand that not everybody in GNOME agrees about gnome-shell. Not every developer is working on it. Please do not think that if you voice your opinion on desktop-devel-list, you will only be talking to rabid supporters of gnome-shell.
If you had a few problems with it, I would be suggesting that you file bugs. But since you (and others) clearly have issues with the whole concept, it is appropriate to bring it up on desktop-devel-list before it comes time to make a decision about official inclusion in GNOME 2.30/3.0.
If everybody who thinks gnome-shell is stupid refuses to provide that feedback, then you can’t really be upset if others decide to include it. That being said, I’d recommend a less aggressive tone on the list.
@Tom:
“Gnome-Shell is based on a ridiculous stupid idea. The only way to improve it is to completely ditch it.”
And yet you fail to provide any concrete criticism. Did you even try it out?
@Sandy:
Well I’m running GNOME Shell and GNOME Do in parallel atm and while there certainly is some duplication of possibilities in such a setup (as is in the GNOME 2.x-world) both can happily co-exist.
Well, I’m not happy about gnome-shell,
1. There seem to have been no input from any usability experts (at all). There is no working binaries for ordinary people (ordinary people don’t know how to compile) to try thus you won’t get the input you are after.
2. It’s written in javascript? wtf? I don’t need another java-engine running all the time.
global-menu seems very Mac-like and would be far more preferable than gnome-shell at this time.
gnome-do is almost a must.
@Mårten W: I don’t get what Java has to do with JavaScript.
A first tarball has now finally been released – ask your distribution to provide a package that you can install if you want to try gnome-shell.
aklapper: I should have said javascript-engine then?
@suka Excellent, I’m glad they’re running well together. Still, if gnome-do were to be an official GNOME module, I would expect the two to complement each other.
@Marten: I think it’s interesting that you don’t mind using Mono (a VM) to run gnome-do, but you do mind running a Javascript engine (another VM) for gnome-shell. If you get a chance to try the new preview release, maybe you should do some performance comparisons to see if there’s actually an impact. Otherwise what difference does it make?
@Sandy: Only thing you have to do is change the Shortcut for GNOME-DO as GNOME Shell is atm using the Windows-Key to open the actitivites overlay. Besides that I totally agree with you, lots of possibilities for better coordination here…
Mårten W,
1) Red Hat has usability experts working on it.
2) Javascript has nothing to do with Java
Do some basic research before spouting off random nonsense.
Gnome shell binds the Windows key by default? That’s really stupid for platform independence. What will they bind to if you don’t have a Windows key? (Yes I know its not about the label on the keyboard, but my keyboard doesn’t have a super key..)
Updating my uncomplete list of interesting modules for myself:
banshee, dconf, f-spot, gnome-do, gnome-global-menu, gnome-packagekit, gnome-scan, gnome-shell, tracker, vala, zeitgeist.
Dont forget the scripting languages!
Many apps are great (like f-spot etc..) but the very ability for somewhat “normal” users to create simple desktop widgets in their scripting language is a HUGE selling point for quite many people (be it on Gnome, or on Kde)
In regard to ghex, it is split into two parts, libghex which only uses non-deprecated libraries, and the program which uses many of the deprecated libraries. It might make sense to rewrite the program in vala and gtkbuilder.