Re: Agnubus?
On Thu, Nov 01, 2007 at 01:57:05PM -0400, J French wrote: > I hate OOo with a passion. It may be fine for Windows, but so many other > applications are better under Linux. I was hoping there was something > GTK-based > for this as well. > > Perhaps it's time to start a new project. There's also the powerpoint viewer 'present' written by Chris Lahey a few years back based on the goffice library. Coupled with some of the new docs for PresentationML it should have some useful elements. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring and dbus
Ross Burton wrote: > On Mon, 2007-10-29 at 18:44 +0100, Jan de Groot wrote: >> since last upgrade of my arch, the gnome-keyring didn't work anymore. >> When launching the gnome-keyring-manager tool, it told me, that no >> keyring daemon was active, and the following message was shown on the >> console: "** (gnome-keyring-manager:8715): WARNING **: couldn't >> communicate with gnome keyring daemon via dbus: The name >> org.gnome.keyring was not provided by any .service files" > > Hm, I thought I'd filed a bug with a service file for this too, in fact > we're shipping it in Poky. We've been seeing this issue since gnome-keyring-sharp got D-Bus support. I filed this bug some time ago: http://bugzilla.gnome.org/show_bug.cgi?id=421554 Some applications are now working around the failed activation of the keyring daemon by disabling gnome-keyring support and storing credentials in GConf. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: User's preferred search tool
Hi, On 11/2/07, Denis Washington <[EMAIL PROTECTED]> wrote: > Why not use the xesam spec? We could just have one generic GNOME search > tool that sends xesam queries and presents the search results, > regardless of which search engine gave them us. This would require a > xesam interface for basic file search, but that shouldn't be much of a > problem. I don't think anyone is in disagreement, but this is easier said than done. Beagle, for instance, doesn't use D-Bus for its standard IPC, so it's not just a matter of implementing an additional D-Bus interface. There are some largely historical and now irrelevant reasons for this, but it's not a trivial endeavour. Also, I think there is a warranted apprehension among the desktop search developers as to whether implementing a largely untested spec is a good idea. It's not really any different than the situation that comes up whenever anyone wants to add API to GTK+. That is, people won't use the API until it's in GTK, but you don't want to add (and freeze) an API in GTK if it's essentially unused and untested. For GTK, libegg has been a reasonable solution to this problem. For Beagle, that was the idea behind first implementing Xesam as an adaptor rather than entirely ripping out our existing IPC mechanism. Part of the problem is that we need more manpower. We need someone (or more than one person) to implement a Xesam-based client application that is not designed with any one search system in mind. Porting the existing abstracted backends in GTK+ and Nautilus would also be a worthwhile task. Only with those clients in combination with the various search services that implement Xesam will we really know how well it works in practice. So get to work. ;) [1] Joe [1] FOCUS you BABOON! [2] [2] http://mail.gnome.org/archives/gnome-list/1998-November/msg00294.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
I'll throw in a positive comment for latex-beamer. If you're already comfortable with LaTeX, beamer makes it very easy to put together very nice/modern looking slides, with step-by-step reveals, even outputting to a nice PDF that can be used for presenting on most any OS. http://latex-beamer.sourceforge.net/ -- Michael R. Head <[EMAIL PROTECTED]> http://www.suppressingfire.org/~burner/ http://suppressingfire.livejournal.com smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
Le vendredi 02 novembre 2007 à 11:04 -0400, Hubert Figuiere a écrit : > > > OOo is Gtk based for several years. > > > > This is not true. OOo only uses Gtk themes, not Gtk widgets. Big > > difference. Like the difference between firefox and epiphany. > > What difference does it make to the users? It looks like it. Yes, but there are many subtle differences in behavior (and sometimes in look) that make these apps (OOo and ff) feel "wierd" on a GNOME desktop. That's my own opinion, of course. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
> > OOo is Gtk based for several years. > > This is not true. OOo only uses Gtk themes, not Gtk widgets. Big > difference. Like the difference between firefox and epiphany. What difference does it make to the users? It looks like it. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
Introducing Gnupresent (as in New Present, not guh-noo present ;) ) http://sourceforge.net/projects/gnupresent We'll see how well this goes. J French wrote: > Is this dead? I can't even find where to get the code. If it is indeed dead, > what replaced it? > ___ > 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: [Usability] Mousetweaks usability discussion
Hi All: The spec Calum is referring to is at the following URL: http://accessibility.freestandards.org/a11yspecs/kbd/keyboard-access-func-spec.html In particular, the "Configuration and Setting Requirements" table contains the most pertinent information with respect to what needs to be adjustable and what the numerical ranges should be. Will Calum Benson wrote: > > On 1 Nov 2007, at 12:45, Willie Walker wrote: > >> Anyway, my main point is to ask real users about what tasks they >> typically want to accomplish with mouse keys. Then, figure out the best >> UI that provides the user with the ability to customize mouse keys >> behavior so they can accomplish these tasks efficiently. The reason I >> list the XKB/AccessX stuff above is that they provide the main technical >> constraints to can help/hinder providing what the end user really needs. > > There's also an impending LSB accessibility spec that recommends which > AccessX features ought to be exposed in its configuration GUI, which I > guess we should try and stick to at a minimum (KDE is already compliant > with the draft, IIRC). Not sure when it's due to be published, though... > > Cheeri, > Calum. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
On Qui, 2007-11-01 at 14:15 -0400, Hubert Figuiere wrote: > On Thu, 2007-11-01 at 13:57 -0400, J French wrote: > > I hate OOo with a passion. It may be fine for Windows, but so many > > other > > applications are better under Linux. I was hoping there was something > > GTK-based > > for this as well. > > OOo is Gtk based for several years. This is not true. OOo only uses Gtk themes, not Gtk widgets. Big difference. Like the difference between firefox and epiphany. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: User's preferred search tool
On 02/11/2007, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> wrote: > > On 02/11/2007, Dylan McCall <[EMAIL PROTECTED]> wrote: > > > > > everyone's best interest to standardize this. All we need now is a > > standard. > > > Ok, short answer to long mail - I'm at work so I shouldn't be reading > d-d-l :-) > > XESAM is *exactly* what you talk about. See http://xesam.org. If you are > interested I suggest you read the RC1 spec an give your comments on the xdg > list at freedesktop.org. > Sorry for spamming - I just wanted to point out that #xesam at FreeNode is also available if you have IRC inclinations. Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: User's preferred search tool
On 02/11/2007, Dylan McCall <[EMAIL PROTECTED]> wrote: > > These search engines all provide similar outputs, do they not? What we > need, then, is a standard system that they can each fill in for via D-Bus, > or by replacing some small GNU-esque applications, with the assumption that > the distro's dependency management can deal with overlapping systems. > Hard-coding anything like this is the wrong way to go, because the solution > ends on whatever it was hard-coded for. You will always bump into a person > like me who hates maintaining code, who refuses to implement a system in his > applications when it arbitrarily runs searches as if by hand. That system > will not be long lasting, and will be continually in flux, so the various > applications integrated in the GNOME desktop just won't want to use it. What > happens then? The same thing that happens with a lot of other systems: > Nothing. No lasting good comes of it, because whatever has been hard-coded > to will grow out of the rigid cage that has been set, and a lot of effort is > wasted. Maybe a few programs will duplicate the code, (the viral GNOME foot > logo spinner comes to mind), but that's not really an attractive thing. > Let's make desktop search worth something! This should be consistently > present as a tool that the user can expect to use, rather than one he is > occasionally given the privilege of encountering. > > If a search engine wants to integrate with GNOME's services, it should > provide particular inputs and outputs. I can't see a selection in Preferred > Applications causing any notable changes in the user interface, so that > shouldn't be too difficult to expect with this solution either. The current > option of choosing search filters could be done such that options for > filters are defined, again in a standard way, by search engines themselves. > Leave the rest to the standard interface, whether the existing systems > follow the rules yet or not. (Those filters would need something to ensure > that applications calling the preferred search engine can safely specify > wanted file types or source folders. Individual applications can get away > much more than GNOME with hard-coded behaviours, such as tag searching if > that is available). > > Need an intermediate solution? Fine, implement search tools for Beagle and > Tracker while we wait for them to create GNOME integration packages. By the > way, this is no more to ask than that they have a GTK-powered front-end. > Don't feel bad about having to lock these to a set output and input; they > can still grow on the inside, and the possibilities unlocked far outweigh > the potential benefits of more fancy search options that only are accessible > from a single place. Besides that, we wouldn't be restricting their growth; > the accepted standards can grow, too. A building usually has a single front > entrance, but that doesn't mean the side doors don't exist for those who > want them. Also, just because we're using the same set of doors doesn't mean > we never see improvements in functionality beyond the standard. One building > may have a shiny metal chute for its front door, so getting in and out is > much quicker than the usual staircase! > > Having a centralized, extensible search engine selection that works is > definitely Very important for GNOME's future, and needs to be done right. > This would offer a huge step forward. I have been chanting a lot today, in > various channels, about how it seems the most intuitive interfaces try hard > to abstract file management. It appears that people like photo management > tools, desktop search and web-based document editors. > Why? Why not just use the local file manager and its nice thumbnails? > I think it is because these tools do not require the constant fussing with > file hierarchies we see with a lot of software. This doesn't happen when > there is a single integrated suite for everything (ie: iLife), but we can't > do that here. The more intuitive behaviour is where the program can deal > with file management, (which always ends up quite a hopeless mess thanks to > how files are displayed in any common file manager), and keep that away from > the user's attention. For example, a centralized backup solution is an > excellent thing for the long term, because it means that applications (which > know their own file management techniques quite well) can help the user with > their backups. Instead of one having to pick through backups to recover his > F-Spot library, he could tell F-Spot to find and restore its own darn files, > and it could seek them out and find them (asking for the user's input along > the way, for example which backup to use) all using a common software > interface it can expect to exist for backups. Many stop there, however, and > leave seeking up to the user if he wants to use another program, because > these things just don't know (or seem to care) that each-other exists unless > it is one of those annoying p
Re: User's preferred search tool
Why not use the xesam spec? We could just have one generic GNOME search tool that sends xesam queries and presents the search results, regardless of which search engine gave them us. This would require a xesam interface for basic file search, but that shouldn't be much of a problem. Cheers, Denis On Thu, 2007-11-01 at 20:29 -0700, Dylan McCall wrote: > These search engines all provide similar outputs, do they not? What we > need, then, is a standard system that they can each fill in for via > D-Bus, or by replacing some small GNU-esque applications, with the > assumption that the distro's dependency management can deal with > overlapping systems. Hard-coding anything like this is the wrong way > to go, because the solution ends on whatever it was hard-coded for. > You will always bump into a person like me who hates maintaining code, > who refuses to implement a system in his applications when it > arbitrarily runs searches as if by hand. That system will not be long > lasting, and will be continually in flux, so the various applications > integrated in the GNOME desktop just won't want to use it. What > happens then? The same thing that happens with a lot of other systems: > Nothing. No lasting good comes of it, because whatever has been > hard-coded to will grow out of the rigid cage that has been set, and a > lot of effort is wasted. Maybe a few programs will duplicate the code, > (the viral GNOME foot logo spinner comes to mind), but that's not > really an attractive thing. Let's make desktop search worth something! > This should be consistently present as a tool that the user can expect > to use, rather than one he is occasionally given the privilege of > encountering. > > If a search engine wants to integrate with GNOME's services, it should > provide particular inputs and outputs. I can't see a selection in > Preferred Applications causing any notable changes in the user > interface, so that shouldn't be too difficult to expect with this > solution either. The current option of choosing search filters could > be done such that options for filters are defined, again in a standard > way, by search engines themselves. Leave the rest to the standard > interface, whether the existing systems follow the rules yet or not. > (Those filters would need something to ensure that applications > calling the preferred search engine can safely specify wanted file > types or source folders. Individual applications can get away much > more than GNOME with hard-coded behaviours, such as tag searching if > that is available). > > Need an intermediate solution? Fine, implement search tools for Beagle > and Tracker while we wait for them to create GNOME integration > packages. By the way, this is no more to ask than that they have a > GTK-powered front-end. Don't feel bad about having to lock these to a > set output and input; they can still grow on the inside, and the > possibilities unlocked far outweigh the potential benefits of more > fancy search options that only are accessible from a single place. > Besides that, we wouldn't be restricting their growth; the accepted > standards can grow, too. A building usually has a single front > entrance, but that doesn't mean the side doors don't exist for those > who want them. Also, just because we're using the same set of doors > doesn't mean we never see improvements in functionality beyond the > standard. One building may have a shiny metal chute for its front > door, so getting in and out is much quicker than the usual staircase! > > Having a centralized, extensible search engine selection that works is > definitely Very important for GNOME's future, and needs to be done > right. This would offer a huge step forward. I have been chanting a > lot today, in various channels, about how it seems the most intuitive > interfaces try hard to abstract file management. It appears that > people like photo management tools, desktop search and web-based > document editors. > Why? Why not just use the local file manager and its nice thumbnails? > I think it is because these tools do not require the constant fussing > with file hierarchies we see with a lot of software. This doesn't > happen when there is a single integrated suite for everything (ie: > iLife), but we can't do that here. The more intuitive behaviour is > where the program can deal with file management, (which always ends up > quite a hopeless mess thanks to how files are displayed in any common > file manager), and keep that away from the user's attention. For > example, a centralized backup solution is an excellent thing for the > long term, because it means that applications (which know their own > file management techniques quite well) can help the user with their > backups. Instead of one having to pick through backups to recover his > F-Spot library, he could tell F-Spot to find and restore its own darn > files, and it could seek them out and find them (asking for the user's > input along the way, for exa
