Vincent: > The fact that the Project Ridley page might be outdated is one of the > reasons why we're trying to have a new process to periodically update > the roadmap. > > Replacing libart_lgpl with cairo is a good example of something you > should suggest to the roadmap gang when you'll get the mail asking about > your plans and ideas. This is something that sounds good, but we just > need to coordinate ourselves (and we hope the new roadmap will help with > this).
It might be good to be a bit specific in the questionnaire about Platform versus Desktop roadmap issues. Since the Platform is special it might be good to try and get people to think more about the future direction of the Platform, in addition to just general ideas about \GNOME's future. >> I'd think there are other interface stability issues that should also >> be tracked in our RoadMap. For example, how are end users supposed >> to integrate with various FreeDesktop specifications. Should people >> be encouraged to use Portland interfaces or gtk-update-icon-cache, >> update-desktop-database, and update-mime-database? >> >> http://portland.freedesktop.org/wiki/ > > My personal opinion is that we should directly use > gtk-update-icon-cache, etc. But again, this is something high-level that > could be raised as part of the roadmap process. We can use this process > to identify open questions and get answers to them. Yes, it would be nice to get some traction on some of these higher-level issues. I think the RoadMap process could be used to help facilitate discussion on these sorts of questions. >> Are there any plans to expand the GNOME Platform to include any >> libraries that are needed to write a reasonable GNOME application? >> Or will the Platform shrink to remove no-longer-needed libraries >> such as libgnome? I don't think there has been any real discussion >> about what we're doing in this area for a while, so it might be >> worth some discussion. > > As long as we keep our API/ABI stability, we can't remove libraries from > our platform. Therefore, the first question would then be: do we want to > break API/ABI? My understanding was that it's really something we want > to avoid. Of course, we can always discuss this if there are strong > arguments to break API/ABI. I'm not suggesting the GNOME community should break API/ABI at all. I just think that the GNOME community isn't very clear about which Platform Libraries should be used going forward and which ones are maintained just for backwards compatibility. If I'm a new user/developer/ISV/whatever, then how do I know which Platform libraries I should focus on using? I don't think the GNOME community is very clear about this today. >> It would be nice to perhaps identify what interfaces the GNOME desktop >> should provide to end-users which are not currently provided. For >> example, there is no stable/recommended interface for adding applets to >> the panel, or shortcuts to the desktop. Are there features like this >> that should be considered in a RoadMap? > > In the roadmap process, yes. I can't tell you this is the kind of stuff > that might be in the roadmap document at the end of the process, though: > what you're proposing here is too detailed for a GNOME-wide roadmap (but > it could be perfect for the panel and nautilus roadmaps). It could be > good for the GNOME-wide roadmap if you say "be friendly to ISD/ISV who > want to nicely integrate", which is something a bit more general. I think I'm just suggesting that we think more about what barriers might prevent people from considering the GNOME desktop seriously as an integration platform. What sorts of things would cause a 3rd party to think, "well if I can't do that, this desktop really isn't mature enough for what I want to do". In Windows, for example, you end up with all sorts of crufty little background programs in your panel that slow down your CPU. Would it turn away some ISV's if they can't do the same thing in GNOME, or is a feature that we protect your CPU by not providing this feature? :) I also note some programs like Rhythmbox install similar widgitry things in your panel when they run. Do we want these sorts of interfaces exposed and supported to users outside of the GNOME project? Likewise with the notification daemon. If we want 3rd parties to use it, should the interfaces be a part of the Platform? Questions like this. >> Since improving interface stability is an ongoing effort, it seems >> a RoadMap is a good place to keep track of how far along we are, and >> where we hope to go. Though, perhaps this is out of scope of what >> you are planning to do with this. > > It's definitely something that the roadmap can help with. I'm not sure > this should be done within the roadmap process, but it can rely on the > roadmap process. I think any attention made to improving the Platform and making it more clear to end-users what they should use, and how, is a part of improving interface stability. So, if the RoadMap helps in this area, then I think it is (in some way) a part of the process. But this is just my thinking. Brian _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
