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
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
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
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
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
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
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
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
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
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
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
* 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
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
(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
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
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
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
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:
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
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
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?
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
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
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
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
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,
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
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
28 matches
Mail list logo
