Re: Lowering barriers
It would be really sleek if we came up with a utility that could do this for Gnome/GTK apps, and I think it would lower the barrier for people to try to start developing. If we had something that worked like, say: ghack --python --docs --intl projectname A few years ago, when I was starting out with GNOME, Gtk+ and the autotools, whenever I wanted something like this, I'd fire up glade-2 and create a mini-project with all the files I needed by clicking on the Build button. I'd then munge the generated files to get what I wanted. Maybe ghack could start from the old glade-2 code to get what you want. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
I think bumping functionality to plugins is a pointless operation, especially in a desktop environment that tries to follow the idea of having a lot of small programs that each do simple tasks very well. Interfaces like D-Bus let us create top-level applications (for lack of a better term in my dictionary) act like plugins by communicating all sorts of information with applications in an intuitive, generic way. The coolest thing with that sort of functionality is that there is a lot of room for standardization, such that programs can interoperate via D-Bus with other programs that they were not even intended to work with. This plugins madness, on the other hand, involves every program having its own silly way of doing plugins. In addition, like joined windows handled by individual programs themselves to represent multiiple documents (a ramble I will leave for another day; bottom line: Fluxbox does it right), the extra processes are effectively concealed from lower level systems. I can't say I am hugely knowledgeable about the lower level systems that I vaguely mention for fear of sounding like too much of an oaf, but I know there are already systems that handle resource distribution and memory management for processes they know how to handle. These plugin systems tend to do that same thing in their own ways, but those ways happen to be much less carefully crafter and do not have years of attention behind them. Besides that, those plugin systems rarely offer functionality we cannot get through even a separate program. One unusual example is Epiphany's extensions. Those tend to be very simple plugins that trigger single additions to the core behaviour of the program. Going through the dialog where they are chosen, it feels a lot like regular program preferences, and that is made moreso by the unusual ability for extensions to immediately start working without the need for a browser restart. For example, I can turn on the Tab Sizer extension and have my tab bar immediately sized to always fit on the screen with no need for scrolling. In theory, Evolution's plugins would offer that same feel, but they don't really. I think a reason for that is they often add /a lot/ of functionality and require configuration; one must peel through two layers of configuration tools to get what he needs. Instead of Epiphany (Resize tabs to fit window? Block ads? Scroll with middle mouse?), Evolution's plugins are a lot of groups of yet more options (IMAP Features) -- although this isn't always the case, for example with Block plain text. Frankly, I think the underlying flaw is in Evolution's core design. It is built to be a very big program, promoting very big plugins; if each plugin there just did a single thing each, we would have not just tens, but hundreds of them! Clearly, the problem of having an enormous core was observed and acted upon, but the solution just creates a new problem: A lot of plugins, which feels frighteningly similar to KDE. A smoother course of action, and one which fits more with the expected behaviour of GNOME software, would have been (and still would be) to split Evolution into a bunch of individual programs. Not just sub-programs handled by a miniature operating system, but actual individual tools; Mail, Calendar, Notes, etc. This way they are modular components in a way that other applications can easily work with, and, most importantly, those preferences dialogs shrink to a tiny fraction of their initial size. No need to split Mail, Calendars, etc. via tabs; the options can be easily divided and quickly figured out by the easy idea that these are different programs, with different top-level windows. In the places where plugins do still serve their purpose, they can be much simpler plugins built for each component. Plugins could be nicely aimed at certain components, so instead of being for Evolution as a whole, being for Evolution's mail handling system. Most importantly, when functionality so significantly unusual that it couldn't fit in the core of Evolution still wants to work within Evolution's systems, it would not have to be implemented as a huge plugin, but as a simple alternative to one of its major components, easily implemented by adhering to some standards so that it looks the same as the old component (to Evolution's different programs), and otherwise being a completely normal application visible in the main menu. Bye, -Dylan McCall On Nov 14, 2007 12:50 PM, Baptiste Mille-Mathias [EMAIL PROTECTED] wrote: On May 17, 2007 5:26 PM, Vincent Untz [EMAIL PROTECTED] wrote: Moving features to plugins/extensions = (thanks to Baptiste for having raised this specific issue) One of the first thing people are doing with plugins/extensions is moving some of the current features there. It often makes sense from the code point of view, since things will be cleaner. But it doesn't always make sense for the user. I wanted to bring back
Re: Rise of the Plugins
On Wed, 2007-11-14 at 14:26 -0800, Dylan McCall wrote: I think bumping functionality to plugins is a pointless operation, especially in a desktop environment that tries to follow the idea of having a lot of small programs that each do simple tasks very well. Interfaces like D-Bus let us create top-level applications (for lack of a better term in my dictionary) act like plugins by communicating all sorts of information with applications in an intuitive, generic way. The coolest thing with that sort of functionality is that there is a lot of room for standardization, such that programs can interoperate via D-Bus with other programs that they were not even intended to work with. *snip* Frankly, I think the underlying flaw is in Evolution's core design. It is built to be a very big program, promoting very big plugins; if each plugin there just did a single thing each, we would have not just tens, but hundreds of them! Clearly, the problem of having an enormous core was observed and acted upon, but the solution just creates a new problem: A lot of plugins, which feels frighteningly similar to KDE. A smoother course of action, and one which fits more with the expected behaviour of GNOME software, would have been (and still would be) to split Evolution into a bunch of individual programs. Not just sub-programs handled by a miniature operating system, but actual individual tools; Mail, Calendar, Notes, etc. *more snippage* I think you've hit on a great point here, and while I don't know much about the logistics and internals of Evolution, I would certainly welcome splitting it into several smaller programs. While a large all-in-one program is better for office environments which use all the functionality, everyone else is less likely to use all of it. For example, the memos and tasks parts of Evolution may be usurped by Tomboy for certain people; other people might want to just use the e-mail functions, and not bother with calendars or tasks. Yet others might want to use Evolution's tasks and memos, but keep their e-mail on Gmail. Another problem I've been thinking about is how Soylent could/should interact with e-d-s as far as contacts go. I can foresee people wanting to use Soylent to manage all their contacts, but use Gmail for their e-mail. Soylent would require e-d-s to be installed though, and they wouldn't want or need it for anything else. This big, monolithic daemon is being installed and run, and they're only using a small part of its functionality. There should be a better way. You could solve this with huge plugins, but as you say, I think we might want to look at splitting Evolution up, and having the components interact via DBus so that no functionality is lost, but instead extra flexibility is gained. I hope that something like this can happen, and while I can't currently have a go at it myself, I'd hope to in the future. Philip Most importantly, when functionality so significantly unusual that it couldn't fit in the core of Evolution still wants to work within Evolution's systems, it would not have to be implemented as a huge plugin, but as a simple alternative to one of its major components, easily implemented by adhering to some standards so that it looks the same as the old component (to Evolution's different programs), and otherwise being a completely normal application visible in the main menu. Bye, -Dylan McCall On Nov 14, 2007 12:50 PM, Baptiste Mille-Mathias [EMAIL PROTECTED] wrote: On May 17, 2007 5:26 PM, Vincent Untz [EMAIL PROTECTED] wrote: Moving features to plugins/extensions = (thanks to Baptiste for having raised this specific issue) One of the first thing people are doing with plugins/extensions is moving some of the current features there. It often makes sense from the code point of view, since things will be cleaner. But it doesn't always make sense for the user. I wanted to bring back to discussion to the list because originallythe the thread ended in a discussion about licence, but there was no discussion about the UI / usability of plugins in the GNOME applications. I've just open a bug concerning Evolution regarding the way plugins are handled. (http://bugzilla.gnome.org/show_bug.cgi?id=496839) As more and more application comes with their plugin infrastructure, it would be nice to have a great solution :) Thank you -- Baptiste Mille-Mathias Les gens heureux ne sont pas pressés (merci vuntz) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Re: Bumping avahi requirement for GNOME to 0.6.21
On Nov 14, 2007 9:44 AM, Shaun McCance [EMAIL PROTECTED] wrote: Oh, and didn't we agree at the last r-t meeting to have build break requests moved from d-d-l to release-team@, in order to lower the mail s/build break requests/external dependency changes/ What in the world does build break requests mean anyway? I need more sleep or something... volume there? We need to update that wiki page with the new instructions... That would preclude me from seeing the requests. While none of the freezes require approval from the documentation team approval, the release team often makes their UI freeze break approvals contingent on approval from the documentation team. This has nothing to do with freezes and freeze break requests and there are no plans to change those. On a related note, is this the authoritative page for freezes? http://live.gnome.org/ReleasePlanning/Freezes I thought it was agreed that UI and string breaks required notification to the documentation team, but I don't see any mention of that on the page. I'll gladly fix it, unless I'm mistaken about the notification requirement. Um, it almost looks more historical taking a look at it, but we have page that is more official. Feel free to fix it up. Thanks! Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evolution Plugins (Was Re: Rise of the Plugins)
Hi All, Some of the issues that were discussed (here and in #496839) and my personal take on them will be: 1) Plugin list being un-manageable I am thinking of adding a smart-search-box which will query based on plugin-names and pre-defined-tags associated with each plugin. This will make it easy to find out the plugin that you are looking for. Do you have any suggestion for how you want the Evolution Plugin-manager to look like ? Can you send any mockups that you have in mind ? 2) Some plugins should not be shown This may not be possible as people may not want a functionality implemented by a plugin. Disabling this plugin helps them to save screen-real-estate (menu-items etc) and reduces memory foot-print. If any of the core feature is implemented as a plugin, I accept that it should not be shown in the plugin-manager and will happily remove it from the plugin-manager list. (It should have been core-code than a plugin in the first place though) HTTP Calendars and IMAP Featuers are not core features since it may not be needed by everyone. Say a corporate Evolution-GroupWise user. 3) Splitting Evolution into individual applications I have seen this asked by people a few times. But I wonder what good a mail-client or Calendar-client will be without an addressbook. Evolution shell will not load a component (Tasks or Notes) unless you click open the component (except for addressbook) explicitly. But some people have a mis-conception that all components are always loaded (and hence consumes memory etc.) IMHO a better approach will be to make the user choose what components he want to see in his Switcher. Say if someone wants to use only Mailer and Address-book, do not bother showing the Calendar component in the switcher. Atleast for me, It will be far more useful than launching two or three applications everyday morning (Mail/Calendar/Tasks) 4) Evolution Preferences Dialog is Horrendous Yes. This is a terrible thing to have especially when you are working in low resolution. The reason why this was so mammoth was because even the plugin configurations were added to the General preferences. From 2.12 onwards, we have Configure support for plugins and hence people can configure plugins within the plugin-manager window itself. attachment-reminder plugin's configure UI has been already moved from General preferences to Plugin-Manager-Configure already. Work is on for Automatic-Contacts and other plugins already. One another option will be to show the preferences of the current component alone. Like if you launch preferences from Mailer component then only Mailer preferences should be shown. -- Sankar Gnome-Evolution Plugins Maintainer Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evolution Plugins (Was Re: Rise of the Plugins)
Hi, On Wed, 2007-11-14 at 23:56 -0700, Sankar P wrote: Hi All, Some of the issues that were discussed (here and in #496839) and my personal take on them will be: 1) Plugin list being un-manageable I am thinking of adding a smart-search-box which will query based on plugin-names and pre-defined-tags associated with each plugin. This will make it easy to find out the plugin that you are looking for. Do you have any suggestion for how you want the Evolution Plugin-manager to look like ? Can you send any mockups that you have in mind ? To me, this just sounds like a work-around for the problem of simply having too many plugins, although it will probably work OK if the current system is kept. 2) Some plugins should not be shown This may not be possible as people may not want a functionality implemented by a plugin. Disabling this plugin helps them to save screen-real-estate (menu-items etc) and reduces memory foot-print. If any of the core feature is implemented as a plugin, I accept that it should not be shown in the plugin-manager and will happily remove it from the plugin-manager list. (It should have been core-code than a plugin in the first place though) HTTP Calendars and IMAP Featuers are not core features since it may not be needed by everyone. Say a corporate Evolution-GroupWise user. 3) Splitting Evolution into individual applications I have seen this asked by people a few times. But I wonder what good a mail-client or Calendar-client will be without an addressbook. We currently have the other extreme: several different applications each have their own take on the address book (and then each have their own different ways of integrating/syncing it with e-d-s). Why not just have one desktop-wide address book (I'm thinking Soylent here), and have the mail application use that instead? This would give us the opportunity to swap out the address book application in favour of other things if necessary, such as an application which would use some web service as an address book. Evolution shell will not load a component (Tasks or Notes) unless you click open the component (except for addressbook) explicitly. But some people have a mis-conception that all components are always loaded (and hence consumes memory etc.) I must admit I had that misconception, and I'm glad to hear that Evolution lazy-loads things like this, but I can't help thinking that it's a bit of a work-around for having a program which is just too big. IMHO a better approach will be to make the user choose what components he want to see in his Switcher. Say if someone wants to use only Mailer and Address-book, do not bother showing the Calendar component in the switcher. But that's effectively like turning the components into plugins, and then disabling some of them; it comes back to the problem that core functionality shouldn't be in plugins, and you might as well split off such plugins into separate applications. Atleast for me, It will be far more useful than launching two or three applications everyday morning (Mail/Calendar/Tasks) Isn't that what your startup programs list is for? :-P Regards, Philip 4) Evolution Preferences Dialog is Horrendous Yes. This is a terrible thing to have especially when you are working in low resolution. The reason why this was so mammoth was because even the plugin configurations were added to the General preferences. From 2.12 onwards, we have Configure support for plugins and hence people can configure plugins within the plugin-manager window itself. attachment-reminder plugin's configure UI has been already moved from General preferences to Plugin-Manager-Configure already. Work is on for Automatic-Contacts and other plugins already. One another option will be to show the preferences of the current component alone. Like if you launch preferences from Mailer component then only Mailer preferences should be shown. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
