Re: Gnome Applets
Where can I find a tarball of Ryan's work? http://blogs.gnome.org/desrt/2006/08/21/your-domain-lowercaseca-is-expiring/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
First, keep up the good work with Tracker - it's an exciting project! * The scope of Tracker isn't clear. Is the point to be fast search for files, or for all the user's data? To what end has Tracker achieved its goal? It should be clear - to be the best To be the best what? This is exactly my point. Is the idea to index everything or is the idea to index some subset? Is the idea to store all application data, or specific metadata? Part of the problem here I think is that it isn't clear to people how we use Tracker to improve our desktop experience. To be the best first class object database, indexer and search tool. To take up Joe's point, best is a word with no information content - every software project wants to be the best, even extreme crack like WinFS. Comparing the two, what parts of the mythical WinFS does tracker NOT aim to do? Feature-wise, not remain vaporware. :-) At some point of any interesting software design, there will have to be a trade-off, such as memory for CPU for disk, or comprehensiveness for quality, or search result precision for recall, or ease of third-party plug-in development for execution efficiency, or everything is in a fast database for I can fall back on grep and vimacs when I need to, or whatever else. I admire the tinymail project because it is explicitly and deliberately targeting low-memory environments. This does mean (IIUC) that it can't do Evolution-style virtual folders. Tinymail is the best for a particular, focused problem, and the suck for a different problem. This sense of specifics is what I think questions like index everything or ... index some subset? and store all application data, or specific metadata? are trying to get at. Once again, keep up the good work. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Global keybindings in GNOME
By putting the bindings in the one WM process the idea was to keep a
centrally maintained global binding set.
The problem (which I think Alex Gravely originally raised) is that if
you want to run a different WM (e.g. running Tomboy on XFCE), then
apps have got to roll their own keybindings, rather than rely on
metacity. So, after all this debate out getting Tomboy into GNOME,
let's discuss letting Tomboy play nice outside of GNOME... ;-)
Also there was (at least the state of play a year ago when I last
looked - maybe this has migrated to GTK since)
libegg/treeviewutils/eggaccelerators.{h,c} for parsing things like the
string AltF12, which is more than just what XGrabKey gives you,
and should really be somewhere other than egg. But maybe it already
is (or am I getting confused with GtkCellRendererAccel??), and I'm
just old-fashioned (and should remove
deskbar-applet/deskbar/keybinder/eggaccelerators.*).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deskbar Applet 2.16 will not feature NewStuffManager
FYI'ing y'all to say that the previously mentioned NewStuffManager will not be part of the upcoming deskbar-applet 2.16. Also, deskbar-applet no longer depends on elementtree, which was added as a dependency during the 2.15 development cycle. However, I hope to see the NSM code back in development soon after 2.16 is released. For those who want a head-start, I saved the bits I cut out and attached it to http://bugzilla.gnome.org/show_bug.cgi?id=350165 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Global keybindings in GNOME (was: Tomboy in Desktop)
Deskbar-applet has this aswell (same code). I think GNOME needs some API for registering global keybindings. IIRC someone did some work on providing an actual UI for user defined keybindings (instead of the current mess with gconf). Isn't it logical to give apps a way to hook in to this aswell? Yeah, I think that a generic keybinding API would be useful. I remember collecting a list of keybinding bugs somewhere due to the fact that there's a bunch of duplicated code that's slightly different. Things like Superspace works as a keybinding for Open Terminal (handled by gnome-control-center???) but doesn't work for metacity's run-custom-command thingies (or vice versa??). I suppose I could dig up the bugzilla IDs, hang on... Would it make sense to have a single D-Bus service where tomboy, deskbar, metacity, etc. (and don't forget our KDE friends) can just say notify me on AltF12, or is that just total crack and should we just have a traditionally linked libkeybinder instead? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Is it really that hard to check a digital signature? I wouldn't think so, but the fact is that we haven't implemented it yet, and we're in all sorts of freezes by now. Also, there's the people-security issues of who has access (or how do they get access) to the keys (and is that access revokable, and what happens if somebody crucial gets hit by a bus), and what the final master list URL is (which, as Shaun correctly mentions is part of the API, just like the new D-Bus interface org.gnome.NewStuffManager), how is this list hosted, and how is it updated. There's just a lot of work to get from proof-of-concept code to slapping stable and (not obviously in)secure stickers on it, IMHO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 8/1/06, Vincent Untz [EMAIL PROTECTED] wrote: Would waiting for the 2.18 release cycle be an issue for desbkar? I don't think that there's any issues, but we'll discuss this on deskbar-applet-list. If we do punt to 2.18, will we just rebadge the latest 2.14 as 2.16.0? Leave d-a 2.14 as 2.14, but as part of 2.16? And should we backport as little as possible [1] from HEAD? [1] Well, apart from unbreak-the-build things like the patch to play nice with evolution-data-server 2.16. On 8/2/06, Shaun McCance [EMAIL PROTECTED] wrote: With an automated listy-clicky thing, you don't get to see explicit files, and you have no way of checking against a checksum or a digital signature. Yeah, an example: suppose there's a hypothetical intended-for-use-for-five-years distro that shipped this listy-clicky thing (without some means of verification). One day, years down the track, some user goes through the GUI, and picks up the master list from http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml [1], which links to http://some.web.site/my-awesome-deskbar-extension.tar.bz2. This code looked good at the time it was added to the master list, but in the mean time, the domain registration for some.web.site expired and a villian has picked it up, and now serves up evil spyware versions of the extension to our poor user. Bad. [1] Really, if NewStuffManager is to be part of GNOME, a stable version of NewStuffManager should only point to a master list hosted somewhere under gnome.org, I reckon. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Am I correct in assuming that NewStuffManager could also be used to install Epiphany (Python-)Extensions without too much trouble? Yeah, I think so. deskbar-applet-list would know more details. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
You mean running untrusted code from the Web? Nigel said it would be possible to secure it a bit using GPG keys. Maybe this kind of signing should be made a requirement. Well, should signing be necessary and/or sufficient, and who makes that decision? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
OK, I should have brought this up on d-d-l a month or two ago, at
least before we got all freezy, but I procrastinated. Corner me
sometime and ask for my lame excuses. Anyway, going with better late
than never...
The text below is probably best read at my blog:
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 where it has
new-fangled technologies like screenshots and links, but it's
copy'n'pasted here in case the nitpickers amongst you want to quote
stuff in any ensuing argument^Wdiscussion. 'cos it's not like d-d-l
hasn't been controversial enough in the last few weeks... :-)
Short version: There's this new easily-install-new-deskbar-plugins
thingy people have implemented, aiming for the 2.16 release timeframe.
However, it's, like, easily-download-executables-from-the-internet,
which I don't think GNOME has done before, and so the GNOME community
should have a say in whether or not we push ahead with this.
Long version (really, just go straight to
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 )
One of the things about the 2.14 deskbar-applet release was that,
although it supported third-party plug-ins, the GUI to manage them was
all-but-nonexistant. Basically, whilst you could enable and disable
installed plug-ins via the checkboxes in the preferences dialog, you
couldn't (a) find and install new plug-ins, and (b) update existing
plugins through the GUI -- both of which Firefox lets you do, for
example. Instead, you had to download a file (or download and unpack a
tarball) and copy that to a secret directory
(~/.gnome2/deskbar-applet/handlers/) -- i.e. one that you couldn't
find in nautilus.
In the last few months, Sebastian Pölsterl and the other deskbar
hackers have worked on being able to install new plug-ins through a
friendly GUI. The deskbar-applet-list mailing list discussion starts
in April, continues in May and there's also the PluginManager wiki
page. Here's the current state of play (no, this isn't finalized, yes
there are issues, which I'll touch upon at the end of the tour). First
off, there's a new Check For Updates button on the list of installed
plug-ins.
Clicking on that invokes the NewStuffManager a new (Python) program
that communicates with deskbar-applet via D-Bus. To be precise,
NewStuffManager provides the org.gnome.NewStuffManager service.
NewStuffManager is not deskbar-applet specific, and could provide any
app with update info. The app-specific part is another Python file,
deskbar-applet's spec is the only instance so far, and looks like
this:
OPTIONS = {
repo: http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml;,
install-path: ~/.gnome2/deskbar-applet/handlers,
}
And note that it mentions
http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml,
which is the master list of plug-ins and their versions. The intention
is that distros can customize this URL, if they choose to. An example
snippet of that XML file looks like this:
item
idyahoo.py/id
nameYahoo! Search/name
descriptionSearch Yahoo! as you type/description
authorDeskbar Team [EMAIL PROTECTED]/author
version3.1.1/version
urlhttp://raphael.slinckx.net/deskbar/repository/yahoo.py/url
/item
NewStuffManager will note that there is a new version of the Yahoo
handler, and the UI will show that it is updatable.
Clicking on Update will show a progress dialog box, and under the
hood, download the newer yahoo.py from
http://raphael.slinckx.net/deskbar/repository/, unpack the archive (if
necessary), and copy those files to the right place in the file
system: ~/.gnome2/deskbar-applet/handlers/. Note that this is the
user's installed plug-ins, not the globally-shared (and
only-writable-by-root) plug-ins at /usr/lib/deskbar-applet/handlers.
The other thing to notice is the New Extensions tab. Switching to this
tab will invoke NewStuffManager to check the master list for
installable plug-ins. It looks like this:
Again, the Install button will download and install the plug-in. There
really isn't much difference between updating existing plug-ins and
installing new ones, apart from that the user was (probably) aware of
an existing plug-in beforehand, and updating an existing plug-in might
involve an active existing plug-in.
That's what it looks like. It is indeed easier to find and install
plug-ins than before. And plug-ins rock, since they make users go, I
rock. However, there are two very significant issues:
Security: We will be downloading arbitrary Python files, which could
be executed whenever the deskbar-applet initializes all of its
plug-ins. This could be a major security hole. Personally, it's not
that I don't trust Raphael or his web-site, or the third party
websites that he chooses to endorse, but I don't trust (the worst of)
the internet. We don't have digital signatures or other verification
mechanisms implemented yet (and GNOME 2.16 is due only a few months
from now). Auto-update (and auto--removal of obsolete files) is
another issue that should be considered - whilst it
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
thingy people have implemented, aiming for the 2.16 release timeframe. So are you asking for official inclusion of this for 2.16? Deskbar is already part of GNOME, as of 2.14. NewStuffManager is in the Deskbar 2.16 codebase, so if there are no actions to the contrary, then this will become part of GNOME 2.16. However, since being told that things like new dependencies should be announced on desktop-devel-list, the existence (and implied blessing) of NewStuffManager should at least be announced on d-d-l. But also, arguably, this is a new dependency of sorts, even if developed under the Deskbar umbrella rather than as a separate package. And there are these two questions of security and privacy - so it's a little more complicated then applying s/elementtree/NewStuffManager/ on the statement NOTE: deskbar-applet has a tiny new dependency called elementtree. So I wrote this long e-mail to d-d-l in anticipation that the GNOME community would want to discuss this before we release (deskbar-applet + NewStuffManager) as part of 2.16. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Call For Help: Roll deskbar-applet 2.15.90.1
As previously mentioned, deskbar-applet doesn't build against e-d-s HEAD - there is a trivial patch to d-a attached to http://bugzilla.gnome.org/show_bug.cgi?id=347988 which looks good to me (and looks good to others). However, I am running GNOME 2.14 on my sole computer at the moment (a laptop with a far-too-small hard disk), and I don't have the bleeding edge jhbuild built (or have otherwise built e-d-s 2.15.x). Consequently, I can't make the patched tarball because I can't, er, make. So, I would muchly appreciate [1] it if somebody with appropriate privileges could check out deskbar-applet HEAD (I don't think it's changed since I rolled 2.15.90 a couple of days ago), apply the trivial patch mentioned above, update configure.ac, NEWS and the ChangeLog, make a 2.15.90.1 tarball, make distcheck, scp the resultant .tar.gz to master.gnome.org and install-module the sucker. Raphael (kikidonk) is on vacation (??) until the 29th, and I don't know if the other deskbar folks have sufficient privileges to make a release, so I might need a hero to step up right now. Otherwise, I can have another go at it in the (Australian) morning, but it would rock if somebody could help out now. There are simply not enough hours in the day :-( Nigel. [1] I'll buy all applicable people a bunch of beers the next time GUADEC is in Australia, for example. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
Due to some concerted effort from lots of awesome volunteers Thanks be to awesome volunteers. the winners of today's build breakages are: deskbar-applet: :-( I'll roll 2.15.90.1 sometime in the next 12 hours. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
(1) deskbar-applet added a new external dependency (elementtree) without notice being given to d-d-l. In general we've sucked at letting maintainers know that they need to announce new external dependencies (and that the community needs to agree upon them, though there's an assumed acceptance unless someone voices objection), so we probably can't go too hard on them. The dependency is probably sane, considering that it looks like it'll be part of python-2.5 anyway. But it, like dependencies added in other modules, should have at least been announced. :) Deskbar uses elementtree to parse a really small XML file. This could be easily re-written to use another XML parser, removing this new dependency. Is libxml2 the blessed XML library (if one has been blessed at all)? Is it problematic that Deskbar is written in Python - i.e. would libxml2's Python bindings be yet another new dependency?? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
Mostly, we just need to get people into the habit of announcing new dependencies that they want to use, For the record - is desktop-devel-list the appropriate place to raise such announcements? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
er, until we had shifted to using python 2.5 OK, given that GNOME 2.16 will not depend on (the unstable) Python 2.5, I'll re-write the elementtree stuff to use libxml2, unless I am advised otherwise. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
* Bare bones Do we take the current core module list, or should we strip it down to move, say, Vino to a sysadmin bundle with Pessulus and Sabayon? It would be helpful to have a full and complete list of all the applications which are currently part of the core desktop. It would also help to have some idea how to handle panel add-ons (ideally, the core would be C only, and deskbar would move elsewhere) I remember that, some handfuls of months ago, Jeff Waugh [1] proposed a Power User Tools suite outside of the traditional Platform / Bindings / Desktop (/ Admin). IIRC he was musing about things like Brightside and Devil's Pie, but one option might be to spin out Tomboy, Deskbar, and suchlike into that. Just one more idea to fling around the zoo. :-) [1] I think it was Jeff, but for some reason my GoogleFu is weak and I can't find a reference in the mail archives. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
Are there any plans to integrate Tomboy with the new Memos-backend in evolution-data-server 1.6? As always, if there are volunteers who are willing to pitch in and get the ball rolling, I would only be too happy to support the effort and do my bit for it. s/support the effort/be a Summer of Code mentor/ ?? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: policy request: 'make uninstall' should work
On 4/9/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote: support 'make uninstall' Should this be an upcoming Gnome Goal?? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop as Nautilus
I also have such a monitor and one thing I've been missing is a way to mouse click on the window switcher. I also have a window switcher button on my mouse, the MX1000. I would be nice if this button activated the window switcher where the mouse was and would then let me click on the application icon instead of going all the way to the menu and clicking on an icon there. It pops up in the middle of the screen, rather than where the mouse is, but you might want to check out superswitcher. Currently, it binds to the Super key, but you could possibly bind your fancy mouse button to that, too. http://www.gnomefiles.org/app.php?soft_id=1231 screenshot: http://blogs.gnome.org/attachment/nigeltao/2006/01/02/1/superswitcher.png It also does a lot more, such as find-as-you-type search for windows, and keyboard shortcuts for add/remove workspaces. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop as Nautilus
If it's in the bottom right corner of the screen (as it is in Ubuntu's default setup, for example), it's several thousand pixels wide and several thousand pixels high, making it the easiest thing to drag to in the whole of Gnome. Except when, like me, you want panel hide arrows turned on :) In which case, you stick it in almost the corner, and it's still very easy to hit - slam the mouse into the corner, and then just the slightest flick of the wrist in the opposite direction. Two movements, both fast according to Fitts - the first one has a superlarge target area, the second one is a short distance. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Please, let's stop cross-posting, and settle on desktop-devel-list. There is a difference between having applets somewhere and having the officialy inside the desktop environment. That's a good point. Currently, Deskbar (which hopefully will be the hot new verb of 2006 :-) is hosted on GNOME CVS, tracks issues with GNOME Bugzilla, and discussions take place on a GNOME mailing list. Even if it does not make part of the official GNOME 2.14 module set, I would like to release 1.0 at the same time as GNOME 2.14, and be of comparable quality. Contact-lookup-applet is similarly in GNOME CVS, but out of the official GNOME desktop, and my distribution ships it as part of a standard GNOME install. That's all good. So what gain would Deskbar have to be stamped as officially Part Of GNOME? One is bigger exposure of (in my humble, biased opinion) useful functionality. Two is simply bragging rights and some Wow in What's new in GNOME 2.14. More subtly, other applications can then rely on the Deskbar being part of GNOME. It's extensible, so that, for example, Tomboy can supply a Deskbar back-end - simply a page or two's worth of Python in the right place - so that you can type a fragment of a note title to jump to that note. Downsides? It pulls in the Python gnomeapplet bindings as a dependency, but I believe that this is not an issue. It duplicates some existing functionality (mini-commander, contact-lookup-applet) although I would like to think that Deskbar is better and others can be deprecated. Inclusion in GNOME adds an expectation that it will be maintained in the future, as part of GNOME 2.16, 2.18, and so on. I'm happy with that. It's also a bit of a power user feature, and probably won't help me get laid [1]. :) And of course, there are quality (i.e., performance) concerns - memory consumption and startup speed. Like everybody, I would like smaller and faster, but I don't think that the Deskbar is fundamentally problematic, PROVIDED that it is an optional feature, and not part of the default desktop experience (and therefore not replace the Alt-F2 run dialog, at this point in time). Some people have tried it and found it wanting by their standards, and they would decline the option. That's fine by me. Nigel. [1] http://www.jwz.org/doc/groupware.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 2005-10-25 at 00:35 +0200, Benoît Dejean wrote: - deskbar-applet startup is as long as full gnome startup: 6s for loading the applet on my ppc 1GHz. - Memory usage on startup : 22MB RES Performance is a concern, but also one I do not want to attack prematurely. For example, python per se may not be the culprit, but rather the fact that we have to parse and index browser bookmarks and history files. Perhaps a better solution would have such database queries provided by an epiphany-data-server appended to the current evolution-d-s. Start-up time may not be that big an issue if it's a one-off and doesn't stop you otherwise using your desktop. This may be a bigger concern for those who want to replace the Alt-F2 Run dialog. Also, my understanding is that there is a difference between getting deskbar into GNOME, and getting deskbar into (onto?) the default GNOME desktop. We've shipped mini-commander for a number of years now as a power-user feature. Regardless, starting quicker and taking less memory are almost always worthy goals. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Auric Implemented (mostly!?)
For those who follow the AuricApplet idea on live.gnome.org, those who downloaded previous versions of my deskbar, or simply those who are nostalgic for how epiphany used to be able to search from the address bar, I announce the Deskbar Applet version 0.4. It's been a few months coming. It's been majorly overhauled, re-written, and sexed up (now with libsexy goodness). It does beagle, it talks icons, it gives you your web and gtk bookmarks, files and folders, apps like abiword, flickr, imdb, cddb, wikipedia, google, yahoo, a9, and the kitchen sink*. Really, it's a lot slicker than version 0.3 Watch the screencast (approx 5MB flash file, generously hosted by sourceforge - you might have to try it a couple of times, though): http://browserbookapp.sourceforge.net/deskbar-screencast.html Homepage: http://www.gnomefiles.org/app.php?soft_id=780 Comments? Nigel. * well, address book integration is pending Python bindings for evolution-data-server. But that never stops a good mock-up. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Auric Implemented (mostly!?)
The keyword part is the worse feature in Firefox, and looks like the worse in Deskbar as well. In Epiphany, IMDB would just be another choice in the drop-down menu (it looks like there's only searching the web via google in there most of the time). Obviously, the Epiphany developers have their reasons for rejecting the keyword feature, and Epiphany is indeed a delightfully non-bloated piece of software. The drop-down menu just doesn't scale, though, when you want to have a bunch of search engines on hand. Just my opinion. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
On Wed, 2005-06-15 at 10:09 +0800, Davyd Madeley wrote: On Tue, 2005-06-14 at 11:13 +1000, Nigel Tao wrote: ABOUT: This is a small Gnome applet that is like Google's Deskbar, but it 1) runs on Linux, and 2) can use search engines other than Google. This is pretty nifty. Thanks, mate. Admittedly, I use my applet less often these days, since Epiphany can Google directly from the location bar. And as a full-blown application, Epiphany gets a global keyboard shortcut, which (AFAICT) an applet cannot. Kudos to the Ephy guys - it rocks my world! Nigel. Tip #1: Stick the Deskbar Applet in the bottom-left corner (and kick out the show-desktop button) for maximum Fitts goodness. I've been so much less productive when looking up anything and everything in the Wikipedia is just a slam-the-mouse-in-the-corner away. :) Tip #2: I just came across www.yubnub.org a couple of days ago. Add this engine to the Deskbar Applet: u Yubnub http://www.yubnub.org/parser/parse?command=%% ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
On Wed, 2005-06-15 at 15:58 +0200, Johan Svedberg wrote: * Jun 15 10:22 Nigel Tao [EMAIL PROTECTED]: And as a full-blown application, Epiphany gets a global keyboard shortcut, which (AFAICT) an applet cannot. I think it can, IIRC tomboy does this. Off the top of my head (I currently don't have tomboy installed, so I might be just plain wrong), tomboy has a shortcut to open a new window (i.e., a new note), but I want a shortcut to shift focus to an existing window (or, more precisely, a GtkEntry inside an applet inside a panel). This may or may not be an important difference. I tried to code something up a number of months back, pre-2.10, but got stuck. It might be easier now, with the new request_focus API. One more for the TODO list, I guess. :) Also, possibly off-topic, tomboy's keybinding code is some Xlib magic, written in C (as opposed to the rest of Tomboy, in C#), rather than a GNOME or GTK API. If I wanted to re-use the code, but not just blind copy-and-paste, what's the process for bumping such a thing up into GNOME, and where should it live? libegg? Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Three Point Zero - Idea Mockups
Since gnome.conf.au, I have been chewing on a few thoughts for GNOME 3.0. And the in recent months, the community (wiki, lists, planet, etc.) have come up with a ton of suggestions, both wacky and very wacky. A number have inspired me - there are too many to list. Anyway, I got around to writing up a few things, and GIMPing up some really shoddy mockups. Now, I throw my crazy ideas into the ring. The two key themes are 1) first class objects, and 2) search as interface, and things kinda flow from there. http://browserbookapp.sourceforge.net/topaz/ Enjoy, Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
