Re: Module proposal: gio and gvfs for gnome 2.22?
On Mon, 2007-09-24 at 14:56 +0200, Étienne Bersac wrote: > Hi, > > I vote for. I'm also wondering how much extra code this will require for > software to use this. It depends on what you do with it. Most applications currently using gnome-vfs mainly use it to load/save files. That should be easy to replace. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
On Mon, 2007-09-24 at 20:06 +0100, Philip Withnall wrote: > Hi, > > On Mon, 2007-09-24 at 20:44 +0200, Vincent Untz wrote: > > Hi, > > > > Le lundi 24 septembre 2007, à 04:00 +0100, Alex Jones a écrit : > > >Hi list > > > > > >What do we want from the next version of GNOME Panel? > > > > > >Do we want to evolve it or just replace the dependency on Bonobo for > > > now? > > > > > >I think that unifying the concept of applets and more heavyweight > > >"widgets" might be beneficial, unless anyone can think of any good > > > reason > > >why not to. Any GDesklets developers here? > > > > I've been thinking about this, and it's indeed important to come with a > > reply to this kind of questions. The goal is not to remove the bonobo > > dependency, but to get a better API for applets. Removing bonobo is more > > of a side-effect to me. > > > > About applets & desklets: I've no strong feeling here. On one hand it > > makes some sense since they might be similar for the implementation, but > > on the other hand I don't expect the clock displayed in the panel to > > look and behave like the clock on a desktop. > > How about if the applets/desklets were unified, but had different > interfaces according to whether they were docked in the panel, or on the > desktop? Thus, you'd end up with a clock which looks spiffy when on the > desktop, and is more compact and "boring" (:-P) when docked in the > panel. > > Philip This sounds much like KDE 4's Plasma, which has applet backends (which provide the needed information, like the time for a clock applet) and the frontend (user interface which can use one or more backends) separated. That would indeed be cool. It's a pitty that we use another language and toolkit than KDE, we could share so many core technologies... :( > ___ > 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: GNOME Panel++
On Tue, 2007-09-25 at 01:36 +0300, Lucas Rocha wrote: > Why not: > > http://live.gnome.org/GnomePanel/Future > > It's a saner place to add those things. Sure, go for that. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Hi, 2007/9/25, Alex Jones <[EMAIL PROTECTED]>: > > On Mon, 2007-09-24 at 16:41 -0500, Benjamin Gramlich wrote: > Alex, what will the address for the wiki be? > > http://live.gnome.org/FuturePanel > > Feel free to start putting ideas down if you want. I was gonna wait a few > days before aggregating our ideas from this thread. Why not: http://live.gnome.org/GnomePanel/Future It's a saner place to add those things. --lucasr ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
Hi!, On Mon, 2007-09-24 at 12:23 -0400, Matthias Clasen wrote: > Since everybody is making proposals for 2.22, here is my contribution: > we should merge the clock applet with the intlclock that Novell has written. > > David and I have done some further work on it to support timezone > setting and weather information, I'd like to remind that there is already a DBus interface for modifying time settings in system-tools-backends, easily accessible through the liboobs C library. I'd like it to use system bus activation and PolicyKit real soon. Regards, Carlos ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: GtkGLExt for GNOME 2.22
On Sat, 2007-09-22 at 19:10 +0200, Andreas Røsdal wrote: > On Sat, 22 Sep 2007, Vincent Untz wrote: > > Le samedi 22 septembre 2007, à 13:57 +0200, Andreas Røsdal a écrit : > >> Hello! > >> > >> * Proposal: Include GtkGLExt in the GNOME developer platform. > > > > Oh, interesting. > > > > Note that it's possible that it will get rejected for the platform if it > > doesn't go in the desktop for at least one cycle, since we're quite > > strict about the platform. So maybe you should propose it for the > > desktop first? > > I'd like to be pragmatic and propose the module to the release set > which is the most appropriate. Originally, I didn't think that GtkGLExt > should be a Desktop module, because it doesn't "provide user > functionality". But now I see that other libraries such as GStreamer, > gnome-doc-utils and libsoup are included in the Desktop release set as > well - Despite being development libraries, and not providing end user > functionality. Those modules are in the Desktop release set because they are dependencies of applications that are also in that release set. They don't offer any particular guarantees of API/ABI stability, or any promise that you won't need to port to a new version of the API in the near future, though some of them aren't too bad. There would be something odd about saying "Here's a new API for you to use. We don't recommend that you use it." I'd much rather see this done properly in GTK+. > Since GtkGLExt is a development library, and should be part > of the infrastructure / development platform for other modules, the > developer platform was originally the release set that I thought would be > most appropriate. > > So I'm fine with proposing GtkGLExt as a desktop module, at least for the > first development cycle. Generally, more long-term, I think that all > development libraries in the desktop release set should be in the > developer platform release set, ideally. > > >> However, GtkGLExt is currently unmaintained. I will volunteer to maintain > >> it if accepted as a GNOME module, and hope to work with the GNOME community > >> to make it fit in well as a GNOME module. > > > > Well, it won't be accepted if it's unmaintained. So you should do things > > the other way around: start maintaining it before it can get accepted. > > I agree. Should I begin maintaining it in the GNOME infrastructure already > now? Any suggestions about how to proceed during this development cycle > for a "smooth" inclusion as a new module during this cycle? :-) > > >> There has also been a lot of discussion about this in bug #119189 > >> "Add OpenGL support to GTK+". > > > > I gave a really quick look at the bug, and there doesn't seem to be any > > decision there. Are there any specific plans? > > There are no decisions or specific plans that I know of yet. > > - Andreas > ___ desktop-devel-list mailing > list desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
On Mon, 2007-09-24 at 16:41 -0500, Benjamin Gramlich wrote: > Alex, what will the address for the wiki be? http://live.gnome.org/FuturePanel Feel free to start putting ideas down if you want. I was gonna wait a few days before aggregating our ideas from this thread. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Diego Escalante Urrelo <[EMAIL PROTECTED]> wrote: > Speaking of UI, I have a little suggestion (based on the mockup on Fedora > wiki). > I see that below the world map there's a row that has a clock, the > zone and the weather, it's really cool but I can imagine it filling a > 1024x768 screen pretty quickly. I would like to suggest that this rows > are self-aware enough to know if screen space is too short then change > from the "big" expanded view of the mockup to a more table like one > (with the cool graphics and stuff but with fonts a lot smaller). > Yeah, the overall size of the thing is a concern. Maybe that is a reason why the Novell code has options to turn the map and the location list off, individually. Calvin, have you had complaints about the popup being too large ? Btw, the image on the Fedora wiki is not a mockup, it is a screenshot of the applet in action. The wiki page has pointers to all the patches, so you can try it out easily. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Gimmie is very interesting and user friendly. I've always felt that the Gnome panel has been a little bare. SLED was a step in the right direction, but it seems that very few people have been willing to use it. (Actually, isn't Novell the only merchant to use SLED?) I think that the gnome-panel could benefit very much from a redesign that would blend the OSX dock concept with its current UI. Maybe blending some of gimmie's great ideas with some of SLED's improvements. Gimmie would need to be implemented in C, though, wouldn't it? Additionally, Phillip's idea seems to me a good one, but gdesklet may need to be rethought. It's a bit clunky right now. Alex, what will the address for the wiki be? Ciao, bg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
Le lundi 24 septembre 2007, à 17:29 -0400, Bryan Clark a écrit : >On 9/24/07, Diego Escalante Urrelo <[EMAIL PROTECTED]> wrote: > > On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > On 9/24/07, Vincent Untz <[EMAIL PROTECTED]> wrote: > > > Calvin Gaisford and I have been discussing this a few weeks ago and > > > he'll work on getting the two merged. My preference is to use the > > > current backend code, and import the intltool UI in the clock. I > don't > > > think it will be really hard, although I don't know how much work > this > > > involves. I'm a bit unsatisfied with the UI, though, since it means > > > having a lot of information in the popup. So usability input would > be > > > great. > >I'd love to hear some feedback from others. There are some consistency >issues most people can probably spot, like the [Edit] buttons should >probably be [Edit...] since they open other windows to complete the >interaction. Things like that I believe can be done pretty quickly and >aren't worth going back and forth on a mailing list about. > >More obvious changes that are unlike other places in GNOME might warrant >some discussion. Usually GNOME applets would tend towards a hidden Right >Click menu option off the main applet and this design went with having the >Edit buttons appear inline of the interface because I believe if they are >visually less strong than the surrounding parts they provide a more >discoverable set of interactions for the interface. YMMV. This is some of >the cause I've found for people to say the UI looks busier than it has to >be. > >The [Set] button appears only on mouse rollover of the timezone areas, >normally it wouldn't be readily visible. I'm not entirely sold on this >yet, my original design had a different method but I'd like to have this >tested out before trying to make more changes. > >If you have specific areas you feel need improvement I'd be more than >willing to attempt to address them on this or another list if it's more >appropriate. My main concern is that in this popup, you can easily have: + one calendar + one map + three timezones + 7 tasks + 3 appointments + 1 birthday In 2.20, the clock now uses expanders for tasks/appointments/birthdays, so it might mitigate the issue a bit, but I still feel this is overcrowded. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
> I'd love to hear some feedback from others. There are some consistency > issues most people can probably spot, like the [Edit] buttons should > probably be [Edit...] since they open other windows to complete the > interaction. Things like that I believe can be done pretty quickly and > aren't worth going back and forth on a mailing list about. Another cool change would be (dynamically?) swapping between the multiple timezone clocks one over the other to a more compact view with clocks stacked horizontally. My $0.02 -- Alan <[EMAIL PROTECTED]> - http://arcterex.net "Beware of computer programmers that carry screwdrivers." -- Unknown ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Diego Escalante Urrelo <[EMAIL PROTECTED]> wrote: > > On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > On 9/24/07, Vincent Untz <[EMAIL PROTECTED]> wrote: > > > Calvin Gaisford and I have been discussing this a few weeks ago and > > > he'll work on getting the two merged. My preference is to use the > > > current backend code, and import the intltool UI in the clock. I don't > > > think it will be really hard, although I don't know how much work this > > > involves. I'm a bit unsatisfied with the UI, though, since it means > > > having a lot of information in the popup. So usability input would be > > > great. I'd love to hear some feedback from others. There are some consistency issues most people can probably spot, like the [Edit] buttons should probably be [Edit...] since they open other windows to complete the interaction. Things like that I believe can be done pretty quickly and aren't worth going back and forth on a mailing list about. More obvious changes that are unlike other places in GNOME might warrant some discussion. Usually GNOME applets would tend towards a hidden Right Click menu option off the main applet and this design went with having the Edit buttons appear inline of the interface because I believe if they are visually less strong than the surrounding parts they provide a more discoverable set of interactions for the interface. YMMV. This is some of the cause I've found for people to say the UI looks busier than it has to be. The [Set] button appears only on mouse rollover of the timezone areas, normally it wouldn't be readily visible. I'm not entirely sold on this yet, my original design had a different method but I'd like to have this tested out before trying to make more changes. If you have specific areas you feel need improvement I'd be more than willing to attempt to address them on this or another list if it's more appropriate. > > The changes you've made look quite interesting. > > > > The ui bits are based on design input by Bryan Clark. Maybe I should put > some of > > his earlier mockups on the wiki page, too. > > Speaking of UI, I have a little suggestion (based on the mockup on Fedora > wiki). > I see that below the world map there's a row that has a clock, the > zone and the weather, it's really cool but I can imagine it filling a > 1024x768 screen pretty quickly. I would like to suggest that this rows > are self-aware enough to know if screen space is too short then change > from the "big" expanded view of the mockup to a more table like one > (with the cool graphics and stuff but with fonts a lot smaller). > > But that's a minor thing, I think it looks great :). I would avoid an auto-sizing algorithm and suggest something like this as a preference such that it doesn't make the layout too volatile; maybe you could get it right but the details would be very hard. However my real concern would be to layout the information tightly in a manageable format that's still visually clean, I haven't tried and there's probably a much better way out there. Feel free to send mockups or sketches my way if you have ideas. Thanks, ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
Il giorno dom, 23/09/2007 alle 20.31 +0300, Kalle Vahlman ha scritto: > Sorry, but I did get lost while trying Mercurial just now. I can't > understand why I need to merge something that I just committed. I > mean, I just modified a file, committed the change and then tried to > push the committed change to the place I cloned from. The result was a > complaint that it would create remote branches and I needed to merge. > Merge what to where? You don't need to merge if nothing was changed in the original repository: $ # create the original repo and commit a file $ hg init repo1 && (cd repo1 && echo foo > bar && hg add bar && hg ci -m 'First commit') $ $ # clone the original repo $ hg clone repo1 repo2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ $ # do a commit in the cloned repo $ cd repo2 && echo foobar >> bar && hg ci -m 'Foobar' $ $ # push the changes to the original repo $ hg push pushing to /home/demian/Desktop/repo1 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files What did you do to get that message? -- Marco Barisione http://www.barisione.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
Hey! On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > On 9/24/07, Vincent Untz <[EMAIL PROTECTED]> wrote: > > > > > Calvin Gaisford and I have been discussing this a few weeks ago and > > he'll work on getting the two merged. My preference is to use the > > current backend code, and import the intltool UI in the clock. I don't > > think it will be really hard, although I don't know how much work this > > involves. I'm a bit unsatisfied with the UI, though, since it means > > having a lot of information in the popup. So usability input would be > > great. > > > > The changes you've made look quite interesting. > > The ui bits are based on design input by Bryan Clark. Maybe I should put some > of > his earlier mockups on the wiki page, too. Speaking of UI, I have a little suggestion (based on the mockup on Fedora wiki). I see that below the world map there's a row that has a clock, the zone and the weather, it's really cool but I can imagine it filling a 1024x768 screen pretty quickly. I would like to suggest that this rows are self-aware enough to know if screen space is too short then change from the "big" expanded view of the mockup to a more table like one (with the cool graphics and stuff but with fonts a lot smaller). But that's a minor thing, I think it looks great :). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Gimmie applet for 2.22 (was GNOME Panel++)
A quick $0.02: I have been using Gimmie on and off for quite some time now (on and off since its initial checkin) and have found it to be a significant step up in terms of a UI over the current Gnome default. The biggest issues have been with crashers (generally with new/fickle features, all of which have been addressed below in the list of features to be addressed/removed) I would be interested to see a build without all these extras, and see what performance/the memory footprint are looking like, as currently long sessions (days to weeks) can see those grow. However, since we are talking about incorporating it and then _developing_ it for some time, I would be a strong supporter of such a move. I think that since most of its 'cool new features' have been mostly developed, and what would really need to be done is gritty testing/bug work, it might be hard to attract the development base we need to get it stable, but if we can mobilize the workforce and/or provide elegant/sane degradation/fallback to the original gnome-panel, I would be all for such a move. My quick, un-researched $0.02, Kevin Kubasik On 9/24/07, Alex Graveley <[EMAIL PROTECTED]> wrote: > Hi, > > The Gimmie applet has been around for some time. Gimmie is a tab-like > replacement for the main Panel menubar, providing logical access to > the concepts of the desktop[1]. > > For more information, see the Gimmie homepage at > http://beatniksoftware.com/gimmie. Gimmie is stored in GNOME SVN, and > uses GNOME Bugzilla for issue tracking. > > Many use it as a replacement for the default Panel menu, myself > included. I think many novel concepts exist in it's UI, and I find it > to be very usable and featured. > > Looking towards the future, Gimmie is designed to move towards the > Online-Desktop model, while preserving access to the features of the > existing desktop. This is a niche which none of the new Panel or > navigation menu alternatives (let alone other desktops) are pursuing, > and one which I consider pivotal if GNOME is to remain pertinent. > > So I'd like to gauge the interest in having the Gimmie applet included > as part of GNOME. Either as part of the main suite or in an add-on > suite. > > What's needed to make this happen? What concerns do people have? > > Issues that I see: > >* There has not been a new release since 0.2.7, in June. A new > release is brewing, and the Gimmie community is stepping up the > release engineering around a solid 0.3 release. > >* Lack of dedicated maintainer resources. Admittedly, I've been > somewhat lax in my duties due to time pressures. Luckily, several > volunteers have stepped up recently offering to take the reins here > for more reliable releasing. > >* There is an experimental standalone panel version of Gimmie. > This can be branched into a sub-project, or simply not installed by > default. I am *not* proposing to expose this panel alternative as > part of GNOME. There are many other interesting panel alternatives > which are seeing a lot of love. > >* Non-functional placeholders for future features should be removed > (Flickr, Google Office, Friendster integration). > >* GMail contact integration needs to be fixed or removed by default. > >* Ditto for Gaim/Pidgin online status setting. > >* The Tomboy note category may not be useful to include by default. > >* There are a few experimental UI features that should be removed > e.g. the timeline view. > >* Saved email attachments only supports Thunderbird's downloads.rdf > format. I don't know if this feature can be supported with Evolution, > and accordingly may need to be removed for now. > >* .desktop change monitoring has been disabled due to crashes in > the gmenu python bindings. This may have been solved recently, or may > require investigation into better alternatives. > >* Preferences and Administration capplets are merged into a single > Settings category. This can easily be split into separate categories > again, if people want to maintain compatibility with the existing > menubar. > >* The "system" tab is labeled according to the OS's name, e.g. > Linux, Solaris, FreeBSD. If this is contentious, we can rename it to > "Computer", "System", or "Gnome". > >* Different terms are used from the standard GNOME menubar: > Applications->Programs, Preferences/Administration -> Settings. > >* A few important crashers must be fixed[2]. See > http://www.beatniksoftware.com/gimmie/Releases. > >* Next-gen desktop systems are not yet used: Tracker/Beagle for > searching, Telepathy for IM contacts, mugshot daemon for web service > access. I would love to see integration with these in future Gimmie > releases, but they are not yet a standard part of GNOME. > > None of these are too bad, and all could see resolution given the > incentive of GNOME inclusion. That said, it's an ambitious goal to > have something like Gimmie included in the next desktop release, but I > t
Proposing Gimmie applet for 2.22 (was GNOME Panel++)
Hi, The Gimmie applet has been around for some time. Gimmie is a tab-like replacement for the main Panel menubar, providing logical access to the concepts of the desktop[1]. For more information, see the Gimmie homepage at http://beatniksoftware.com/gimmie. Gimmie is stored in GNOME SVN, and uses GNOME Bugzilla for issue tracking. Many use it as a replacement for the default Panel menu, myself included. I think many novel concepts exist in it's UI, and I find it to be very usable and featured. Looking towards the future, Gimmie is designed to move towards the Online-Desktop model, while preserving access to the features of the existing desktop. This is a niche which none of the new Panel or navigation menu alternatives (let alone other desktops) are pursuing, and one which I consider pivotal if GNOME is to remain pertinent. So I'd like to gauge the interest in having the Gimmie applet included as part of GNOME. Either as part of the main suite or in an add-on suite. What's needed to make this happen? What concerns do people have? Issues that I see: * There has not been a new release since 0.2.7, in June. A new release is brewing, and the Gimmie community is stepping up the release engineering around a solid 0.3 release. * Lack of dedicated maintainer resources. Admittedly, I've been somewhat lax in my duties due to time pressures. Luckily, several volunteers have stepped up recently offering to take the reins here for more reliable releasing. * There is an experimental standalone panel version of Gimmie. This can be branched into a sub-project, or simply not installed by default. I am *not* proposing to expose this panel alternative as part of GNOME. There are many other interesting panel alternatives which are seeing a lot of love. * Non-functional placeholders for future features should be removed (Flickr, Google Office, Friendster integration). * GMail contact integration needs to be fixed or removed by default. * Ditto for Gaim/Pidgin online status setting. * The Tomboy note category may not be useful to include by default. * There are a few experimental UI features that should be removed e.g. the timeline view. * Saved email attachments only supports Thunderbird's downloads.rdf format. I don't know if this feature can be supported with Evolution, and accordingly may need to be removed for now. * .desktop change monitoring has been disabled due to crashes in the gmenu python bindings. This may have been solved recently, or may require investigation into better alternatives. * Preferences and Administration capplets are merged into a single Settings category. This can easily be split into separate categories again, if people want to maintain compatibility with the existing menubar. * The "system" tab is labeled according to the OS's name, e.g. Linux, Solaris, FreeBSD. If this is contentious, we can rename it to "Computer", "System", or "Gnome". * Different terms are used from the standard GNOME menubar: Applications->Programs, Preferences/Administration -> Settings. * A few important crashers must be fixed[2]. See http://www.beatniksoftware.com/gimmie/Releases. * Next-gen desktop systems are not yet used: Tracker/Beagle for searching, Telepathy for IM contacts, mugshot daemon for web service access. I would love to see integration with these in future Gimmie releases, but they are not yet a standard part of GNOME. None of these are too bad, and all could see resolution given the incentive of GNOME inclusion. That said, it's an ambitious goal to have something like Gimmie included in the next desktop release, but I think well worth it. Hoping for some inspired, civil debate... Thanks, -Alex [1] From the homepage: * Installed Programs * Connected Devices * CDs and DVDs * Nearby networked computers * Mounted network shares * Printers * System Preferences * Administration Tools * Bookmarked Folders * Office Documents * Tomboy Notes * Audio Files * Movies * Downloaded Files (Firefox, Epiphany) * Saved Email Attachments (Thunderbird) * Instant Messaging Buddies (Gaim, Pidgin) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Hi Vincent: Thanks for asking! We generally try to make sure bugs are filed so there are no surprises. I did a quick bugzilla search and came across the following. Some are gnome-applets related, but I think there might be some opportunity in gnome-panel to help them. http://bugzilla.gnome.org/show_bug.cgi?id=103223 - Notification Area needs keynav. This is a long standing bug which has been the source of much frustration for keyboard only users. The underlying cause has since been pushed to GTK+, but it gives an example of the kinds of things to look for. http://bugzilla.gnome.org/show_bug.cgi?id=342094 - Keyboard navigation in applications menu. I'm not sure I completely agree with this one. http://bugzilla.gnome.org/show_bug.cgi?id=428074 - Mixer applet breaks keyboard navigation. http://bugzilla.gnome.org/show_bug.cgi?id=307981 - Launcher properties provides no way of specifying a keyboard shortcut. http://bugzilla.gnome.org/show_bug.cgi?id=331693 - No keyboard-shortcut for Drawer on gnome-panel. http://bugzilla.gnome.org/show_bug.cgi?id=149495 - keyboard bindings (related to Stickynotes). http://bugzilla.gnome.org/show_bug.cgi?id=463934 - Keyboard accelerators are incoherent (comment from a heavy keyboard user) As a general rule of thumb for tracking down keyboard navigation problems, unplug your mouse and see if you can still access the features of your application efficiently. Thanks! Will On Mon, 2007-09-24 at 20:48 +0200, Vincent Untz wrote: > Hi Willie, > > Le lundi 24 septembre 2007, à 10:01 -0400, Willie Walker a écrit : > > Hi Alex: > > > > Thanks for sending out this call for input. :-) > > > > Being able to reliably interact with the gnome-panel and its applets via > > the keyboard alone would be a major boost to its usability. > > Care to elaborate about those issues so we try to avoid repeating the > same errors again? :-) > > Vincent > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Vincent Untz <[EMAIL PROTECTED]> wrote: > > Calvin Gaisford and I have been discussing this a few weeks ago and > he'll work on getting the two merged. My preference is to use the > current backend code, and import the intltool UI in the clock. I don't > think it will be really hard, although I don't know how much work this > involves. I'm a bit unsatisfied with the UI, though, since it means > having a lot of information in the popup. So usability input would be > great. > > The changes you've made look quite interesting. The ui bits are based on design input by Bryan Clark. Maybe I should put some of his earlier mockups on the wiki page, too. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Hi, On Mon, 2007-09-24 at 20:44 +0200, Vincent Untz wrote: > Hi, > > Le lundi 24 septembre 2007, à 04:00 +0100, Alex Jones a écrit : > >Hi list > > > >What do we want from the next version of GNOME Panel? > > > >Do we want to evolve it or just replace the dependency on Bonobo for now? > > > >I think that unifying the concept of applets and more heavyweight > >"widgets" might be beneficial, unless anyone can think of any good reason > >why not to. Any GDesklets developers here? > > I've been thinking about this, and it's indeed important to come with a > reply to this kind of questions. The goal is not to remove the bonobo > dependency, but to get a better API for applets. Removing bonobo is more > of a side-effect to me. > > About applets & desklets: I've no strong feeling here. On one hand it > makes some sense since they might be similar for the implementation, but > on the other hand I don't expect the clock displayed in the panel to > look and behave like the clock on a desktop. How about if the applets/desklets were unified, but had different interfaces according to whether they were docked in the panel, or on the desktop? Thus, you'd end up with a clock which looks spiffy when on the desktop, and is more compact and "boring" (:-P) when docked in the panel. Philip > Btw, I'd love if you could organize all the feedback on a wiki page so > it'll be easy to look at the list of "requirements" in the future. > > Vincent > 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
Re: GNOME Panel++
Le lundi 24 septembre 2007, à 19:49 +0100, Alex Jones a écrit : >On Mon, 2007-09-24 at 20:44 +0200, Vincent Untz wrote: > > Btw, I'd love if you could organize all the feedback on a wiki page so > it'll be easy to look at the list of "requirements" in the future. > >Yeah, I plan to do this once I've gathered enough of a consensus. Hrm. You might not see us reaching a consensus :-) Even listing things we don't agree with can be useful, IMHO. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Le lundi 24 septembre 2007, à 17:14 +0100, Calum Benson a écrit : > On Mon, 2007-09-24 at 20:48 +1200, Matthew Paul Thomas wrote: > > > Besides the lack of a global menu bar, which John Stowers mentioned, > > another irritant interaction-wise is inconsistency in behavior between > > panel applets. Some applets do something on a single click, others > > don't, and there's no way to tell which just by looking. Some applets > > do something on a double click, others don't, and there's no way to > > tell which just by looking. Some applets open a menu or menu-like > > control, but they differ in whether they make it look like a menu, and > > if you mouse down on the wrong one you can't slide over to the correct > > one like you can with a normal menu bar. Fixing this lack of menu behavior is something that is being considered for new applets. However, I don't think we'll end up with a menu behavior for launchers; any idea on how to fix this inconsistency? > > It would be really neat if the panel could make these behaviors > > consistent. > > To be fair to applet developers, this is partly a HIG issue too-- we > have very little there about applet interaction at the moment. This is > about the sum total, in fact: > http://library.gnome.org/devel/hig-book/2.20/input-mouse.html.en#mouse-interaction-applets Heh. I'd love to see some work from the usability team there :-) Maybe I can bribe some people with ice cream to help? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
On Mon, 2007-09-24 at 20:44 +0200, Vincent Untz wrote: > Btw, I'd love if you could organize all the feedback on a wiki page so > it'll be easy to look at the list of "requirements" in the future. Yeah, I plan to do this once I've gathered enough of a consensus. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Hi Willie, Le lundi 24 septembre 2007, à 10:01 -0400, Willie Walker a écrit : > Hi Alex: > > Thanks for sending out this call for input. :-) > > Being able to reliably interact with the gnome-panel and its applets via > the keyboard alone would be a major boost to its usability. Care to elaborate about those issues so we try to avoid repeating the same errors again? :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Hi, Le lundi 24 septembre 2007, à 04:00 +0100, Alex Jones a écrit : >Hi list > >What do we want from the next version of GNOME Panel? > >Do we want to evolve it or just replace the dependency on Bonobo for now? > >I think that unifying the concept of applets and more heavyweight >"widgets" might be beneficial, unless anyone can think of any good reason >why not to. Any GDesklets developers here? I've been thinking about this, and it's indeed important to come with a reply to this kind of questions. The goal is not to remove the bonobo dependency, but to get a better API for applets. Removing bonobo is more of a side-effect to me. About applets & desklets: I've no strong feeling here. On one hand it makes some sense since they might be similar for the implementation, but on the other hand I don't expect the clock displayed in the panel to look and behave like the clock on a desktop. Btw, I'd love if you could organize all the feedback on a wiki page so it'll be easy to look at the list of "requirements" in the future. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: gio and gvfs for gnome 2.22?
Le lundi 24 septembre 2007, à 10:46 +0200, Alexander Larsson a écrit : > So, does it make sense to add gio (standalone or in an earlier glib > release) and gvfs to the Gnome 2.22 desktop module set? If there's no glib release with gio for 2.22, I think it makes a lot of sense to include gio and gvfs in the desktop release or as external dependencies to encourage everybody to use them. Hopefully, this approach can help get more feedback about the API and it'll be possible to fix issues and shortcomings before freezing it. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
Hi, Le lundi 24 septembre 2007, à 12:23 -0400, Matthias Clasen a écrit : > Since everybody is making proposals for 2.22, here is my contribution: > we should merge the clock applet with the intlclock that Novell has written. > > David and I have done some further work on it to support timezone > setting and weather information, the current status of which you can > see here: > > http://fedoraproject.org/wiki/Releases/FeatureClockApplet > > This is using new technologies that have appeared lower in the stack, > like DBus system bus activation and PolicyKit, and can serve as good > example for how to integrate these into the desktop. > > We want to do some more work on it in the Gnome 2.22/Fedora 9 > timeframe, as is explained on the wiki page. Calvin Gaisford and I have been discussing this a few weeks ago and he'll work on getting the two merged. My preference is to use the current backend code, and import the intltool UI in the clock. I don't think it will be really hard, although I don't know how much work this involves. I'm a bit unsatisfied with the UI, though, since it means having a lot of information in the popup. So usability input would be great. The changes you've made look quite interesting. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote:
> If you read my mail carefully ("merge"), that is exactly what is being
> proposed here.
> Two clock applets makes no sense at all, which is why we did not ship
> the intlclock in F8.
Sorry, I thought you were asking for module proposal acceptance which
is what period we are in now. Wouldn't it be up to the gnome-panel
maintainer (Vincent Untz) what is and is not in his module?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Jason D. Clinton <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote:
> > Since everybody is making proposals for 2.22, here is my contribution:
> > we should merge the clock applet with the intlclock that Novell has written.
>
> Why not include this in the existing gnome-panel module and avoid
> having two competing clock applets? It doesn't seem like creating a
> whole new module for these would be a good idea.
>
If you read my mail carefully ("merge"), that is exactly what is being
proposed here.
Two clock applets makes no sense at all, which is why we did not ship
the intlclock in F8.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > Since everybody is making proposals for 2.22, here is my contribution: > we should merge the clock applet with the intlclock that Novell has written. Why not include this in the existing gnome-panel module and avoid having two competing clock applets? It doesn't seem like creating a whole new module for these would be a good idea. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
2007/9/24, Alex Jones <[EMAIL PROTECTED]>: > > Maybe an "interesting timezones" feature/setting would be useful in GNOME, > so that other apps can join in the fun of multi-timezone awareness, with > just one central place to configure it. > > Or do you think such a feature should only pertain to a clock? Anyone have > any more use cases? > Gnome-System-tools Network profiles and/or NetworkManager could be timezone aware, for example, if I'm on the network "Home" I'm at Canary Islands, but if I'm at the office, I'm at Dublin. The weather applet might be use it too, right now it only uses a plain tree view. On Mon, 2007-09-24 at 12:23 -0400, Matthias Clasen wrote: > > Since everybody is making proposals for 2.22, here is my contribution: we > should merge the clock applet with the intlclock that Novell has > written.David and I have done some further work on it to support timezone > setting and weather information, the current status of which you can see > here:http://fedoraproject.org/wiki/Releases/FeatureClockAppletThis is using > new technologies that have appeared lower in the stack, like DBus system bus > activation and PolicyKit, and can serve as good example for how to integrate > these into the desktop.We want to do some more work on it in the Gnome > 2.22/Fedora 9 timeframe, as is explained on the wiki page.Matthias > ___ 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 > -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Alex Jones <[EMAIL PROTECTED]> wrote: > > Maybe an "interesting timezones" feature/setting would be useful in GNOME, > so that other apps can join in the fun of multi-timezone awareness, with > just one central place to configure it. > > Or do you think such a feature should only pertain to a clock? Anyone have > any more use cases? > One use case I had in mind was evo calendar. It could make it easier to schedule cross-timezone meetings by showing all the times in parallel, or something. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
Nice stuff, it may need some graphic love tho, any particular reason why the clock graphics are 50x50 and 36x36? It would be better to have them 48x48 and 32x32 as our icons. 2007/9/24, Matthias Clasen <[EMAIL PROTECTED]>: > Since everybody is making proposals for 2.22, here is my contribution: > we should merge the clock applet with the intlclock that Novell has written. > > David and I have done some further work on it to support timezone > setting and weather information, the current status of which you can > see here: > > http://fedoraproject.org/wiki/Releases/FeatureClockApplet > > This is using new technologies that have appeared lower in the stack, > like DBus system bus activation and PolicyKit, and can serve as good > example for how to integrate these into the desktop. > > We want to do some more work on it in the Gnome 2.22/Fedora 9 > timeframe, as is explained on the wiki page. > > Matthias > ___ > 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: New clock applet for 2.22
Maybe an "interesting timezones" feature/setting would be useful in GNOME, so that other apps can join in the fun of multi-timezone awareness, with just one central place to configure it. Or do you think such a feature should only pertain to a clock? Anyone have any more use cases? On Mon, 2007-09-24 at 12:23 -0400, Matthias Clasen wrote: > Since everybody is making proposals for 2.22, here is my contribution: > we should merge the clock applet with the intlclock that Novell has written. > > David and I have done some further work on it to support timezone > setting and weather information, the current status of which you can > see here: > > http://fedoraproject.org/wiki/Releases/FeatureClockApplet > > This is using new technologies that have appeared lower in the stack, > like DBus system bus activation and PolicyKit, and can serve as good > example for how to integrate these into the desktop. > > We want to do some more work on it in the Gnome 2.22/Fedora 9 > timeframe, as is explained on the wiki page. > > Matthias > ___ > 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: Module proposal: Empathy for GNOME 2.22
Hi, That's my first mail to this flamewar, i vote for inclusion of empathy. > That really shouldn't be a blocker. Empathy does not aim to replace xchat-gnome (yet). This discussion is only about empathy inclusion at all. Yet it is possible to connect to IRC using telepathy, but empathy is far from xchat integration (auto connection, nickserv integration, etc.). I gues empathy wish to better integrate irc (get codes from xchat-gnome ?). Kind regards, Étienne. -- E Ultreïa ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
New clock applet for 2.22
Since everybody is making proposals for 2.22, here is my contribution: we should merge the clock applet with the intlclock that Novell has written. David and I have done some further work on it to support timezone setting and weather information, the current status of which you can see here: http://fedoraproject.org/wiki/Releases/FeatureClockApplet This is using new technologies that have appeared lower in the stack, like DBus system bus activation and PolicyKit, and can serve as good example for how to integrate these into the desktop. We want to do some more work on it in the Gnome 2.22/Fedora 9 timeframe, as is explained on the wiki page. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
On Mon, 2007-09-24 at 20:48 +1200, Matthew Paul Thomas wrote: > Besides the lack of a global menu bar, which John Stowers mentioned, > another irritant interaction-wise is inconsistency in behavior between > panel applets. Some applets do something on a single click, others > don't, and there's no way to tell which just by looking. Some applets > do something on a double click, others don't, and there's no way to > tell which just by looking. Some applets open a menu or menu-like > control, but they differ in whether they make it look like a menu, and > if you mouse down on the wrong one you can't slide over to the correct > one like you can with a normal menu bar. > > It would be really neat if the panel could make these behaviors > consistent. To be fair to applet developers, this is partly a HIG issue too-- we have very little there about applet interaction at the moment. This is about the sum total, in fact: http://library.gnome.org/devel/hig-book/2.20/input-mouse.html.en#mouse-interaction-applets Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On Mon, 2007-09-24 at 16:46 +0200, Rodrigo Moya wrote: > On Sun, 2007-09-23 at 22:17 +0100, Ross Burton wrote: > > On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: > > > Needless duplication of work covered by Pidgin and Ekiga (and, so far, > > > done better). This is a reimplementation of the wheel. > > > > Empathy is a UI around an IM platform which totally replaces the > > single-application model of pidgin, ekiga, gossip and every other IM > > client. With Empathy I can go online when I login and using the same > > Jabber connection chat in Empathy, see presence in Evolution, and > > transfer files in nautilus. I'll be logged into the Jabber server once, > > and the connection is shared between them. > > > what about IRC? Would we need to have xchat around if using empathy? As > you say, having all those apps not share anything but the network cable > is a pain for users, so I'm all for having a single backend to manage > messaging, included IRC. That really shouldn't be a blocker. IM applications are notoriously crap at handling anything but the basics of IRC. Something like xchat-gnome is a much better idea for IRC and integration in GNOME. -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: gio and gvfs for gnome 2.22?
On Mon, 2007-09-24 at 10:37 -0500, Jason D. Clinton wrote: > On 9/24/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > I've been working on gvfs and gio for a while, and its starting to reach > > some minimal level of maturity. > > As long as there is consensus on a path from gnome-vfs to gio+gvfs, I > would like to see this in 2.22. Which module are you proposing? > Platform? And how long will the transition from gnome-vfs be allowed? There will be no transition as such, gnome-vfs is in the platform and it will remain in the platform until GNOME 3.0. If no applications are using it then you are not obliged to build it, but the platform ABI is fixed. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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
Re: Module proposal: gio and gvfs for gnome 2.22?
On 9/24/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > I've been working on gvfs and gio for a while, and its starting to reach > some minimal level of maturity. As long as there is consensus on a path from gnome-vfs to gio+gvfs, I would like to see this in 2.22. Which module are you proposing? Platform? And how long will the transition from gnome-vfs be allowed? I'd like to hear from some of the powers that be; their opinions are really critical to whether this would succeed or fail. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On Mon, 2007-09-24 at 16:46 +0200, Rodrigo Moya wrote: > what about IRC? Would we need to have xchat around if using empathy? As > you say, having all those apps not share anything but the network cable > is a pain for users, so I'm all for having a single backend to manage > messaging, included IRC. Yes, there is a IRC connection manager for telepathy. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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
Re: Module proposal: Empathy for GNOME 2.22
On Sun, 2007-09-23 at 22:17 +0100, Ross Burton wrote: > On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: > > Needless duplication of work covered by Pidgin and Ekiga (and, so far, > > done better). This is a reimplementation of the wheel. > > Empathy is a UI around an IM platform which totally replaces the > single-application model of pidgin, ekiga, gossip and every other IM > client. With Empathy I can go online when I login and using the same > Jabber connection chat in Empathy, see presence in Evolution, and > transfer files in nautilus. I'll be logged into the Jabber server once, > and the connection is shared between them. > what about IRC? Would we need to have xchat around if using empathy? As you say, having all those apps not share anything but the network cable is a pain for users, so I'm all for having a single backend to manage messaging, included IRC. Also, if it provides a library/backend to be shared amongst apps, can/will Ekiga use that? -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tomboy 0.10 Planning Meeting Tomorrow @ 13:00 PST
Everyone's invited to attend the Tomboy Planning Meeting tomorrow: Who: Everyone who'd like to participate Where: #tomboy on irc.gnome.org When: Tuesday, 25 September 2007, 13:00 PST What: http://live.gnome.org/Tomboy/DevMeetingZeroPointTen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
I'm curious about the overall accessibility of Empathy. Has anyone done a survey of how well it works with existing assistive technologies for GNOME (e.g., GOK, Dasher, Orca, etc.) as well as its keyboard-only access model? Will On Sun, 2007-09-23 at 10:59 +0200, Xavier Claessens wrote: > Hi, > > * Proposal: Include Empathy in GNOME 2.22 desktop. > > * Purpose: Empathy [1] consists of a rich set of reusable instant > messaging widgets, and a GNOME client using those widgets. It uses > Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main > goal is to permit desktop integration by providing libempathy and > libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets > that can be embeded into any GNOME application. > > * Dependencies: >glib-2.0 >= 2.14.0 >gconf-2.0 >= 1.2.0 >libxml-2.0 >gnome-vfs-2.0 >libtelepathy >= 0.0.57 >libmissioncontrol >= 4.33 >gtk+-2.0 >= 2.12.0 >libglade-2.0 >= 2.0.0 >libgnomeui-2.0 >libebook-1.2 >libpanelapplet-2.0 >= 2.10.0 > > * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. > > * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo > and fedora. It is used by Intel for the moblin [2] platform. There is > patches for Totem and nautilus-send-to [3] to make use of > libempathy(-gtk). Someone was working on integration in gtetrinet but I > don't know the status of that work. There is also an epiphany plugin > [4]. Work was being done for GSoC to integrate Empathy into Jockosher > [5]. Empathy is also used by Soylent [6]. > > * GNOME-ness: The community reports bugs in GNOME bugzilla and attach > patches, I review and commit in GNOME's SVN. Some i18n teams already > started to commit translations. I take care of usability thanks to loads > of usability bugs opened by Vincent Untz. User documentation is not > started yet, I guess we can pick gossip's doc and adapt it for Empathy > since the UI is almost the same. > > * Miscellaneous: > - There is patches to support File Transfer, Voice and Video. I think > it will be ready before GNOME 2.22 feature freeze. > - Empathy is still a young project with some bugs but I'm pretty sure > we can fix them in time for GNOME 2.22. > - At some point we'll have same features than Ekiga which is already in > GNOME desktop. The big advantage of Empathy is it uses Telepathy > framework which make easy for desktop integration and means we'll have > VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM > features (private chat, chatroom, presence, avatar, alias, etc), not > only Voice and Video. Ekiga don't have those advantages. > > Thanks, > Xavier Claessens. > > [1] http://live.gnome.org/Empathy > [2] http://www.moblin.org/projects_chat.html > [3] http://www.barisione.org/blog.html/p=100 > [4] http://blog.senko.net/2007/07/19/emphatic-epiphany > [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc > [6] http://live.gnome.org/Soylent > > > ___ > 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: GNOME Panel++
Hi Alex: Thanks for sending out this call for input. :-) Being able to reliably interact with the gnome-panel and its applets via the keyboard alone would be a major boost to its usability. Thanks again! Will On Mon, 2007-09-24 at 04:00 +0100, Alex Jones wrote: > Hi list > > What do we want from the next version of GNOME Panel? > > Do we want to evolve it or just replace the dependency on Bonobo for > now? > > I think that unifying the concept of applets and more heavyweight > "widgets" might be beneficial, unless anyone can think of any good > reason why not to. Any GDesklets developers here? > > Cheers > ___ > 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: Module proposal: gio and gvfs for gnome 2.22?
Hi, I vote for. I'm also wondering how much extra code this will require for software to use this. Regards, Étienne. -- E Ultreïa ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Damien Sandras <[EMAIL PROTECTED]> wrote: > Le lundi 24 septembre 2007 à 11:34 +0200, Ali Sabil a écrit : > > > Then can you explain us how ICE can help when STUN does not ? I would > > > like to see your argumentation here. > > > > > Correct me if I am wrong, but STUN is generally about finding your > > external IP address, and determining the type of NAT you are sitting > > behind, it is just a subset of the techniques needed to achieve a > > quite reliable NAT traversal. ICE as a method, makes use of STUN among > > others. So I don't see why you oppose STUN to ICE ? > > Simply because in most of the cases the "STUN part" of ICE is enough. > STUN won't work when you are behind Symmetric NAT, in that case you should use > a TURN server. > > I know no public TURN server. > > So there are still plenty of cases where ICE proposes a solution that does > not really help. > > Although TURN will almost always provide connectivity to a client, it > comes at high cost to the provider of the TURN server. It is therefore > desirable to use TURN as a last resort only, preferring other mechanisms > (such as STUN or direct connectivity) when possible. > Thank you for the explanation :) > > > I had decided not to participate to that thread, but there are always > > > people who do not know what they are talking about. What a pity. > > > > I am sorry if I don't know what am talking about, it is just that > > Ekiga never worked reliably for me ! > > And did empathy allow you to do a SIP connection using ICE in a reliable > way ? Nop. I don't think that SIP nor H323 are usable for me. Anyway, I am sorry if I offended you in anyway, we can have another discussion about Ekiga if you are interested in having some feedback, I think the main topic for this thread is Empathy, not Empathy vs. Ekiga. -- Ali ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Jason D. Clinton wrote: > I've been diving deeper in to the code involved here and the more I see the > more I dislike. Xavier, it seems that you implemented gossip-telepathy and > then forked Gossip to create Empathy? Can you provide some history for us > please? What is going on here? Various people were involved in adding Telepathy support to Gossip, particularly started off by Eitan Isaacs and continued a lot by Xavier, as well as support from the Gossip upstream. We reached a point where if we'd continued the integration work between Gossip and Telepathy (particularly integrating Mission Control which would take over storing account configuration and controlling presence) it had the risk of destabilising or degrading Gossip's functionality as a stand-alone dedicated XMPP client. After some discussions on the Gossip IRC channel we agreed that given the relatively unproven nature of the Telepathy framework on the desktop, and the dedication of Gossip to just XMPP until this point, that the required refactoring and changes weren't an acceptable risk for the Gossip developers to take. I totally respect that decision, and there's nothing hostile in the decision to branch Empathy development away from Gossip; it was agreed on both sides and I'm very happy to see Gossip development continuing happily as an XMPP client, and to see that we were able to re-use the excellent UI code to form a solid basis for the Empathy widgets as well. Regards, Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le lundi 24 septembre 2007 à 11:34 +0200, Ali Sabil a écrit : > > Then can you explain us how ICE can help when STUN does not ? I would > > like to see your argumentation here. > > > Correct me if I am wrong, but STUN is generally about finding your > external IP address, and determining the type of NAT you are sitting > behind, it is just a subset of the techniques needed to achieve a > quite reliable NAT traversal. ICE as a method, makes use of STUN among > others. So I don't see why you oppose STUN to ICE ? Simply because in most of the cases the "STUN part" of ICE is enough. STUN won't work when you are behind Symmetric NAT, in that case you should use a TURN server. I know no public TURN server. So there are still plenty of cases where ICE proposes a solution that does not really help. Although TURN will almost always provide connectivity to a client, it comes at high cost to the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. > > I had decided not to participate to that thread, but there are always > > people who do not know what they are talking about. What a pity. > > I am sorry if I don't know what am talking about, it is just that > Ekiga never worked reliably for me ! And did empathy allow you to do a SIP connection using ICE in a reliable way ? -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
> I guess you do not know what ICE is ? Do you ? > Last time I checked ICE it was about finding a a quite good routing path (not always the best) between two endpoints for UDP packets. > Then can you explain us how ICE can help when STUN does not ? I would > like to see your argumentation here. > Correct me if I am wrong, but STUN is generally about finding your external IP address, and determining the type of NAT you are sitting behind, it is just a subset of the techniques needed to achieve a quite reliable NAT traversal. ICE as a method, makes use of STUN among others. So I don't see why you oppose STUN to ICE ? > I had decided not to participate to that thread, but there are always > people who do not know what they are talking about. What a pity. I am sorry if I don't know what am talking about, it is just that Ekiga never worked reliably for me ! -- Ali ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Claudio Saavedra <[EMAIL PROTECTED]> wrote: > On Mon, 2007-09-24 at 00:10 -0500, Jason D. Clinton wrote: > > * It appears to be a fork of Gossip and intended to replace Gossip. > > The Gossip author has stated that Gossip is not dead. Gossip has > > telepathy support... > > * It appears to want to replace the default IM client installed in > > distros (Pidgin). > > These are not real concerns. Nor pidgin or gossip are part of the GNOME > Desktop. I'd be worried if gossip were proposed for inclusion in GNOME, > though, but that's not the case. > > And I'm not even stating these facts hold... which is a different > matter, but irrelevant for the discussion ongoing. I agree with Claudio; let's drop these from further discussion. > > * It appears to want to replace Ekiga. There appears to be no buy-in > > from Ekiga developers. There's no IM in GNOME. If there's an effort to create a framework that "appears to want to replace" current technologies I think that's a good thing. In order words: integration. I'm not saying that Ekiga should be dropped. I'm saying that for the time being it's better to have IM support _in_ GNOME than nothing at all. I propose to drop Ekiga from further discussion too. > > * It doesn't implement all of the features it lists as its benefits. > > (maybe could be fixed by 2.22 release) > > These could be interesting issues, *if* they are backed up. If you are > really against empathy inclusion in 2.22, I'd suggest you to focus in > these particular points. * Adds IM support to GNOME That's something that it's currently doing and I think that's a huge benefit. So what is it really missing for 2.22. You mentioned documentation and I think that's something that can be fixed for 2.22, but we would have to ask the Telepathy guys too. Best regards. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
24 sep 2007 kl. 10.54 skrev Ali Sabil: Hi, So I planned to reply to this thread later today but this kind of mud slinging forced me to do so earlier (will try to reply on the subject at hand later though). > On 9/24/07, Jason D. Clinton <[EMAIL PROTECTED]> wrote: >> The critical difference in that analogy is that the thousands and >> thousands of man-hours spent on Gecko are reused in the >> Gnome-ification called Epiphany. As Empathy is proposed, all the work >> in protocol implementation that has come before in the form of Ekiga >> and Pidgin appears to be thrown out the window. > > I guess you never really used Ekiga? did you? > > Ekiga is nowhere near user friendly, am not even sure it is HIG > compliant. It doesn't have any ICE support last time I checked, which > in other words means that it will never work reliably in a > NATed/Firewalled environment (which let me remind you is the most > common case with the proliferation of home routers). Please keep the focus on Empathy and avoid trashing other projects. Focus on why Empathy is better rather than how other projects are worse. If you really care about getting Empathy into the GNOME Desktop you shouldn't alienate GNOME Developers and Users this way. It is especially important in topics such as this to stay on topic, this proposal is already somewhat infectious as it talks about replacing existing GNOME Desktop applications. Also please compare existing features and not potential future ones based on the assumption that one project will implement them and another won't move. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le lundi 24 septembre 2007 à 10:54 +0200, Ali Sabil a écrit : > On 9/24/07, Jason D. Clinton <[EMAIL PROTECTED]> wrote: > > The critical difference in that analogy is that the thousands and > > thousands of man-hours spent on Gecko are reused in the > > Gnome-ification called Epiphany. As Empathy is proposed, all the work > > in protocol implementation that has come before in the form of Ekiga > > and Pidgin appears to be thrown out the window. > > I guess you never really used Ekiga? did you? > > Ekiga is nowhere near user friendly, am not even sure it is HIG Ekiga is a softphone, not an IM, so it is as user-friendly as a softphone can be. > compliant. It doesn't have any ICE support last time I checked, which > in other words means that it will never work reliably in a > NATed/Firewalled environment (which let me remind you is the most > common case with the proliferation of home routers). I guess you do not know what ICE is ? Do you ? Then can you explain us how ICE can help when STUN does not ? I would like to see your argumentation here. I had decided not to participate to that thread, but there are always people who do not know what they are talking about. What a pity. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: nxlaunch: A new GTK NX client
On Mon, 2007-09-24 at 00:04 +0200, Jaap Haitsma wrote: > On 9/23/07, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > Le lundi 17 septembre 2007 à 16:26 +0100, Seb James a écrit : > > > Heads up for those interested in remote desktop connections: > > > > > > I just committed a GTK NX client called nxlaunch to the freenx svn > > > repository at berlios: > > > > This sounds quite interesting, but I would have loved to see this work > > integrated in tsclient instead - unless you are also planning to > > integrate XDMCP and RDP functionality. > > > Or even better vinagre [1] , which is a nice GNOME UI compliant vncviewer Hi Josselin and Jaap, I was aware of vinagre and tsclient. That's why I designed my NX client in two pieces. One is the core program which actually negotiates the connection and leads to a window being created on the screen. This is called nxcl, also available from the berlios svn repo. nxcl has a dbus api for a frontend client to communicate settings to it. You set up the connection (gnome/kde, IP address, username etc) in the frontend, storing it for future use using any means you like (nxlaunch uses an XML file for that). You then send those settings in dbus signals to nxcl (which you have to fork and exec) which actually launches your NX window. nxcl depends only on libdbus-1, libstdc++, glibc and a couple of X libs (it's written in C++) and the total size of the code (.so file plus binary) is about 160 kbytes. That means it should be easy to integrate NX support into both tsclient and vinagre! The one thing that is missing is notification of the X window ID of the NX window that gets created. I have logged a feature request with NoMachine to place that into the libXproxy, nxssh and nxproxy programs. Without the X window ID, it's hard to take the new NX session and, say, stick it in a tab of sessions, or otherwise manipulate it. regards, Seb p.s. I made a mistake choosing the nxlaunch name - it was already in use for a scripted cmd line NX session launcher. For this reason I will shortly be renaming nxlaunch, but the library will still have the name nxcl. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Jason D. Clinton <[EMAIL PROTECTED]> wrote: > On 9/23/07, Xavier Claessens <[EMAIL PROTECTED]> wrote: > > > > I strongly disagree, Empathy do NOT reimplement the wheel! Empathy is > > not just an IM client like all others, it's an IM framework and is the > > only project that makes possible for other applications to integrate IM > > features. > > Isn't that exactly what libpurple is which you mention below (which is > already stable and implemented)? That's not correct. libpurple is _not_ an IM framework, it's not even a conventional IM library either. Basically it's the core of Pidgin, so different frontends (Qt) can be implemented. So if you use libpurple you can only design the UI, not how to store configurations and preferences (libpurple does that for you). http://developer.pidgin.im/wiki/WhatIsLibpurple "libpurple is intended to be the core of an IM program. When using libpurple, you'll basically be writing a UI for this core chunk of code. Pidgin is a GTK+ frontend to libpurple, Finch is an ncurses frontend, and Adium is a Cocoa frontend." It's objectives are quite far from Telepathy ones, it doesn't matter how stable it is. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Jason D. Clinton <[EMAIL PROTECTED]> wrote: > The critical difference in that analogy is that the thousands and > thousands of man-hours spent on Gecko are reused in the > Gnome-ification called Epiphany. As Empathy is proposed, all the work > in protocol implementation that has come before in the form of Ekiga > and Pidgin appears to be thrown out the window. I guess you never really used Ekiga? did you? Ekiga is nowhere near user friendly, am not even sure it is HIG compliant. It doesn't have any ICE support last time I checked, which in other words means that it will never work reliably in a NATed/Firewalled environment (which let me remind you is the most common case with the proliferation of home routers). Pidgin on the other hand is definitely not HIG compliant, and even the library behind Pidgin (libpurple) is unusable, we can have a very long discussions about this, but I guess this is not the main topic here. -- Ali ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module proposal: gio and gvfs for gnome 2.22?
I've been working on gvfs and gio for a while, and its starting to reach some minimal level of maturity. I'm currently working on porting nautilus from gnome-vfs to gio in order to verify that the design works and so that we can fix any problems or bugs. It might also be interesting for other applications to try it out. I believe its possible to get this into shape for Gnome 2.22, so maybe we should start a discussion about this. Let me give a short introduction to it for people who haven't followed the development. "gio" is a gobject-based library that abstracts out various forms of I/O. The long term plan for it is to be part of glib, like libgthread or libgobject. However, to avoid having to branch glib and to make it easy for applications to use before its merged into glib it is currently availible in the "gio-standalone" repository in gnome svn. Here is what libgio currently contains: * Basic input and output stream base classes. These allow both synch and async i/o and is a basic API that many types of streams can implement. Having an api like this at the low level means you can easily connect code from separate modules. * Concrete implementations of streams: local files, sockets and memory buffers. * Streams working on other streams: Buffering, data parsing/writing * GFile - a filename abstraction This is a object that represents something "like" a filename path (but its extensinble so it could be a uri or something different too). It allows you to do all the typical file operations that desktop applications need. * An implementation of GFile for local files * APIs for various things needed for file handling: api for cancelling i/o operations content types icons app info (mimetype->app mapping and opening files with an app) basic volume monitor (for listing volumes in e.g. file selector) file and directory monitoring (fam/gamin/inotify/polling supported) libgio has no hard dependencies apart from glib. It can optionally use various libraries (fam/gamin for file monitoring, libhal for volume monitoring, libxattr/libselinux for some file info details), but these are not exposed directly in the API. Also, some of them will be converted to modules so that they can be picked up correctly at runtime as needed. In fact, libgio is designed to separate out dependencies by allowing apps to depend on abstract APIs, and then letting various implementations fill in these APIs. GVFS is one such implementation, availible in the "gvfs" module in gnome svn. It is a "userspace vfs", similar to gnome-vfs, which plugs into gio. Its shipped as multiple parts: 1) A client library This is a GModule that gets loaded by libgio and implements GFile and the other stuff required to allow files to be accessed and maninpulated. This library only depends on dbus which is used to talk to daemons on the session bus handling the actual i/o protocols. 2) A main gvfs-daemon This daemon registers with the session bus and keeps track of all mounted locations and lets you mount new ones. 3) A horde of mount-daemons Each mounted location is handled by a separate daemon. This protects against instability in other mount daemons, and it makes it easier to implement backends (as they fully control their context). There is also an optional fuse module, so that on systems supporting fuse we can let 3rd party applications not using gio access the mounted gvfs filesystems. Last week I created the nautilus "gio-branch" branch where I've started work on converting nautilus to use the gio apis. Its not yet in a state where is useful, but there is progress. For more details about gvfs and gio here are some references: Slides from my guadec presentations: http://blogs.gnome.org/alexl/2007/07/20/gvfs-presentation-slides/ Mails from me about gvfs: http://mail.gnome.org/archives/gtk-devel-list/2007-September/msg00012.html http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00062.html http://mail.gnome.org/archives/gtk-devel-list/2006-September/msg00072.html So. What is the plan for Gnome 2.22? I'm not sure exactly how this plays out, but it would be nice if we could get something in. Although gio is now shipped separately it is meant to be in glib, and the release schedule for glib is normally tied to gtk+, which isn't planned to release a new version next summer or so. However, mattias has hinted about the possibility of doing a glib release earlier than that to get gio out. Ideally there are some common ui things related to gio that should be in Gtk+ (progress dialogs, password dialogs, etc), but perhaps we could do these in a libeel fashion in the first round. I'd like to hear peoples thoughts here. gio and gvfs aren't yet at a state where its expected to "just work" (not much tested, little docs, etc), but I'm planning to fix that. It would be nice if we could replace gnome-vfs with a more modern API at the right place in the stack as early as possible. So, does it m
Re: GNOME Panel++
On Sep 24, 2007, at 3:00 PM, Alex Jones wrote: > ... > What do we want from the next version of GNOME Panel? > > Do we want to evolve it or just replace the dependency on Bonobo for > now? > > I think that unifying the concept of applets and more heavyweight > "widgets" might be beneficial, unless anyone can think of any good > reason why not to. Any GDesklets developers here? > ... Besides the lack of a global menu bar, which John Stowers mentioned, another irritant interaction-wise is inconsistency in behavior between panel applets. Some applets do something on a single click, others don't, and there's no way to tell which just by looking. Some applets do something on a double click, others don't, and there's no way to tell which just by looking. Some applets open a menu or menu-like control, but they differ in whether they make it look like a menu, and if you mouse down on the wrong one you can't slide over to the correct one like you can with a normal menu bar. It would be really neat if the panel could make these behaviors consistent. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Dodji Seketeli wrote: > As I understand it, libempathy is a set of reusable widgets and > leverages on the telepathy framework. > > That implies that nothing should prevent Ekiga from using > libempathy/telepathy at some point in the future when it is stable and > and has the necessary features. > > Today, a lot of people are using Ekiga because it *works now* for > the softphone use cases. > > SIP and H232 (yes people are still using that one) are complicated in > the sense that just claiming "supporting the specs" is not enough. You > really have to debug your implementation against the buggy behaviours > of the servers that are *already* out there in the real world. > > In that respect, I think that Ekiga is way more mature today than > Empathy. Please correct me if I am wrong here. Right on all counts. Personally my interest in seeing Empathy integrated into GNOME is not for any VOIP or SIP functionality, which is very immature at the moment in the upper levels (the SoC UI stuff isn't merged yet, and the underlying stream engine is in need of some TLC to make it less wedded to the Nokia internet tablet devices), it's to enable other applications to build on top of the Telepathy framework to integrate IM, presence and collaborative functions into other apps in the desktop. > Empathy/Telepathy does look really promising though and I think the > nice thing would be to see some kind of integration work going on at > some point. I mean, one could imagine some telepathy-opal initiative to > take place where necessary, or seeing Ekiga re-using some libempathy > stuff at some point. I agree, I'd love to see this. I guess I've been quite remiss thus far because I've not really had much interaction with Ekiga developers to discuss the prospects for co-operation and integration. A Telepathy opal backend makes a lot of sense, as does using the familiar Ekiga interface to allow users to take advantage of Telepathy functionality which isn't currently available in Ekiga (such as XMPP calling perhaps?). > Cheers, Regards, Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Ar 24/09/2007 am 00:12, ysgrifennodd Alex Jones: > We have legacy transports that provide a basic level of support, but it > will always be a balancing act, much like the reverse-engineering work > in Telepathy/Farsight. Pissing away free development hours chasing a > moving target wild geese just so that we can pretend to be compatible is > irrefutably masochistic, and I'd really like it to stop. But when Nokia > drives a truck of money up to Collabora's offices, I've no problem > there, they can do what they like. Hmm, maybe this truck got lost on the way? If you see it, please let us know. Cheers, -- Dafydd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 21:54 -0500, Jason D. Clinton a écrit : > On 9/23/07, Alex Jones <[EMAIL PROTECTED]> wrote: > Hi Xavier > > On Sun, 2007-09-23 at 23:19 +0200, Xavier Claessens wrote: > > Currently GNOME has no IM program at all, Ekiga does only voice and > > video AFAIK. > Surely you haven't forgotten Gossip already. :P > > FWIW, I'm extremely keen on keeping Gossip going. I personally > feel that Telepathy is potentially dangerous to our cause. I > mean, great, you can voice-video chat with your MSN friends, > but you still need an MSN account. One step forward, two steps > back. > > > I've been diving deeper in to the code involved here and the more I > see the more I dislike. Xavier, it seems that you implemented > gossip-telepathy and then forked Gossip to create Empathy? Can you > provide some history for us please? What is going on here? We first started a telepathy backend for Gossip, then more deep work was needed to integrate well telepathy into gossip and Gossip developers refused that, they wanted to keep Gossip a Jabber-only client. So I forked Gossip to make Empathy to be a telepathy-only client. That's all. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On Mon, 2007-09-24 at 09:03 +0100, Dafydd Harries wrote: > A question about external dependencies: which Telepathy components would be > blessed external dependencies? I'm tempted to say none, just make the packages required at build time external dependencies. Everyone would build gabble and so on, but I think the blessed dependency list should be a small as possible. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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
Re: Module proposal: Empathy for GNOME 2.22
Ar 23/09/2007 am 19:54, ysgrifennodd Travis Reitter: > My main concerns right now are libempathy(-gtk)'s API stability and > documentation. The API in svn trunk has changed since the last release > (0.12), and (as Björn points out) the documentation is basically > non-existent. > > Xavier, could you explain how you plan to address these concerns in time > for the Gnome 2.22 release? Disclosure: I work for Collabora, which sponsors Empathy development. I'm with Travis here. API quality/stability and documentation are weak points. It could probably do with some HIG review too, though I think it's less of a concern as Empathy inherits from Gossip's mature UI design. A possible concern is that libempathy-gtk is GPL rather than LGPL, due to the fact that much of its code is taken from Gossip. A question about external dependencies: which Telepathy components would be blessed external dependencies? I'm in favour of making Empathy a Gnome program, but I don't want it in before it's ready. Putting it in prematurely would be a disservice to our users and developers. -- Dafydd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Ar 24/09/2007 am 00:48, ysgrifennodd Jason D. Clinton: > On 9/24/07, Peter Gordon <[EMAIL PROTECTED]> wrote: > > > So? Distros are free to package and ship GNOME components however they > > see fit so long as they comply with any applicable copyright/trademark > > licensing. Unfortunately, as a good analogy, most tend to ship Firefox > > or Seamonkey as the default browser instead of Epiphany - Does this mean > > we should just stop hacking on Epiphany entirely? That would be far > > counterproductive to GNOME's goal of being a consistent, user-friendly > > desktop. > > The critical difference in that analogy is that the thousands and > thousands of man-hours spent on Gecko are reused in the > Gnome-ification called Epiphany. As Empathy is proposed, all the work > in protocol implementation that has come before in the form of Ekiga > and Pidgin appears to be thrown out the window. Will Thompson has written a Telepathy backend that uses Pidgin's libpurple for protocol support. -- Dafydd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
Le lundi 24 septembre 2007 à 04:00 +0100, Alex Jones a écrit : > Hi list > > What do we want from the next version of GNOME Panel? Use normal X window management protocol to handle applets (à la system tray), that would be the modern way of launching several remote xload to watch a bunch of machines. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
