Re: Proposing Gimmie applet for 2.22 -- check out 0.2.8
Hi, So Gimmie 0.2.8 was just released, and fixes many of the issues I outlined in the proposal mail. It's the most solid release yet, with lots of testing and most major bugs fixed. Check it out! Details inline... On Sep 24, 2007 12:27 PM, Alex Graveley [EMAIL PROTECTED] wrote: 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. Done =) * 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. Work is in progress on getting new maintainers up to speed, and I'm confident I can find the requisite time needed. * 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. Left the standalone dock in for now, as no one weighed in either way on hiding/removing it. * 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. These are all removed for now. Expect awesome support for all these services and more in the 0.3 release. * Ditto for Gaim/Pidgin online status setting. Fixed. * The Tomboy note category may not be useful to include by default. No feedback as yet. * There are a few experimental UI features that should be removed e.g. the timeline view. Done. * 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. I believe Evo/EDS needs further support to support easy external listing of attachments. * .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. Fixed. * 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. No feedback, but I think the split makes sense for transitional users. * 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. No feedback, remains as OS name for now. * Different terms are used from the standard GNOME menubar: Applications-Programs, Preferences/Administration - Settings. No feedback so not changed. Splitting Settings back into Preferences/Administration would leave only the Applications/Programs conflicting with the existing GNOME parlance. * A few important crashers must be fixed[2]. See http://www.beatniksoftware.com/gimmie/Releases. All fixed. * 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. There has been much talk of reusing Empathy, once it gets included in Gnome, to handle a lot of the work of the IM contact management. This should allow for really tight People tab integration. -Alex ___ 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?
Seems like it might be less risky to start in 2.22 by porting all the simpler load/save gnome-vfs users to gio first, to flesh out the API. Replacing an API which has been stable for a few years with an API that hasn't seen much review, has had no releases, and has had no applications ported to use it scares me. If load/save is what most people use gnome-vfs for, why not write a tiny library with a tiny API that does this well, instead of introducing an entire IO framework? Then this library could be implemented using gnome-vfs, or gio, or kio, or fuse, or posix, or win32 on the backend. (Maybe even made part of fdo.) Keeping the API tiny would avoid conflicting with the myriad IO frameworks that exist in the high level language platforms. Maybe I'm misunderstanding and that's the intent of libgio? -Alex On 9/24/07, Alexander Larsson [EMAIL PROTECTED] wrote: 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? I'm thinking maybe Desktop for now, since the API is young and we don't want to freeze it to early. ___ 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?
The file selector and file manager seem like the most pathological users of an IO API. Do we want to expose another largish API because of their requirements? That was what led to gnome-vfs in the first place. ISVs typically don't use gnome-vfs because it doesn't work x-desktop, and I don't see that changing by pushing it lower in the stack. Maybe removing the added dependency burden will make it more accessible, I dunno. Most apps that I use every day (firefox, thunderbird, OOo, emacs) are unlikely to switch to gio for anything other than opening files via the open dialog. So it's not like pushing gnome-vfs lower is going to suddenly make URLs/paths work the same across the desktop. Are there any stats on gnome-vfs usage? Who uses what? Several of the things you mention (content types, icons, app info) are wrappers for xdg specs and tools. I could see that growing to include volume and file monitoring (one can hope). Would growing xdg APIs be more sustainable than exposing libgio as part of glib? Or do you think the uphill battle with xdg is not worth it? (I'll stop being a cranky old fart now...) -Alex On 9/25/07, Alexander Larsson [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 05:29 -0700, Alex Graveley wrote: Seems like it might be less risky to start in 2.22 by porting all the simpler load/save gnome-vfs users to gio first, to flesh out the API. Replacing an API which has been stable for a few years with an API that hasn't seen much review, has had no releases, and has had no applications ported to use it scares me. If load/save is what most people use gnome-vfs for, why not write a tiny library with a tiny API that does this well, instead of introducing an entire IO framework? Then this library could be implemented using gnome-vfs, or gio, or kio, or fuse, or posix, or win32 on the backend. (Maybe even made part of fdo.) Keeping the API tiny would avoid conflicting with the myriad IO frameworks that exist in the high level language platforms. While most apps need code only to load and save files the whole desktop needs more than that. The file manager needs to be able to all sorts of things, and the file selector (that all apps indirectly pull in) need to do a lot more than load and save. libgio is a (relatively small) API which abstracts out what these apps needs and implements support for local files. I'm sure you can make it smaller, but for every user there would be some feature missing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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: MAINTAINERS in svn -- have it or don't get any SVN account approved
Just wondering... is there a point to keeping a separate AUTHORS file, or should we just svn mv these to MAINTAINERS and update the format? -Alex On 8/11/07, Olav Vitters [EMAIL PROTECTED] wrote: On Tue, Aug 07, 2007 at 06:51:31PM -0400, Behdad Esfahbod wrote: On Wed, 2007-08-08 at 00:36 +0200, Olav Vitters wrote: Some Name E-mail: [EMAIL PROTECTED] Userid: svn-account-name Note that the userid is really important. Otherwise ensure that the E-mail address is the one your @svn.g.o alias forwards to. Can you make it understand [EMAIL PROTECTED] address please? Was thinking about it. Will ask Baris if this is possible (don't believe it should be a problem). -- Regards, Olav ___ 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 online desktop - (some of the possible) next steps
Awesome! I've been looking at doing DBUS binding for Pyro, but I'd gladly use yours instead. I don't really understand why you'd expose Firefox's HTTP stack over dbus, or allow DOM manipulation using the same. What do you have in mind? -Alex On 7/23/07, Ian McKellar [EMAIL PROTECTED] wrote: On 7/23/07, Havoc Pennington [EMAIL PROTECTED] wrote: - investigate how HTTP state of browser can be used by any app I'm working on exposing Firefox's HTTP stack over DBus. Should be handy. With this is should also be possible to expose as much browser state as desktop apps might need - right up to grease-monkey-like interaction with web sites. I've basically got the beginnings of a DBus-XPCOM bridge. It seems to kind of work a little bit for the tiny subset of types that I've written the marshaling code for. It's implemented as an XPCOM module that could be installed by an extension or installed system-wide in /usr/lib/firefox/components When it's demoable I'll throw my git tree up and post some binaries. Ian -- Ian McKellar http://ian.mckellar.org/ +1 415 867 9255 [EMAIL PROTECTED]: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. ___ 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: Online Desktop, Tomboy, and user storage
I'm coming late here, but lucky this discussion is dumb so I didn't miss much. The online desktop should allow it's users to dump stuff into their own personal WebDAV space. This is useful for a million and one things. Tomboy exports to WebDAV already. Tomboy can export to a little corner of an online desktop user's online WebDAV space tomorrow. If you want Web-accessible notes, write a web service in whatever language you want that parses the Tomboy DAV notes. Congrats! End of thread. -Alex On 8/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] wrote: * Tomboy remains pretty much unchanged (work to have change notifications from tomboy are underway anyway - its something Sandy already offered to implement for us). * Conduit gains a dataprovider plugin that can sync notes to online.gnome.org through whatever protocol you suggest. This protocol will have to update the Tomboy online data model from the server end. If I understand this, right now I'm coding an implementation of Tomboy's SyncServer and in a Conduit future I would code a Conduit data provider plugin. I think which of those interfaces I write to has very little to do with what I'm talking about coding, right? Am I off base here? The only thing that affects me is whether I code to the SyncServer interface in Tomboy now or a comparable Conduit interface. For now from my perspective the answer is whichever one Tomboy uses - porting Tomboy to Conduit is a separate project from what I'm doing, I would think. I think that is correct. Rather than a SyncServer you would implement a DataProvider for Conduit to be able to talk to your server. And yes, whether or not we are officially blessed as official sync app for GNOME... Conduit will support your interface ;) My problem is just a general worry that more and more apps will go do the roll there own path when Conduit could help, even in the case of Cheese which is looking to add Flickr support. If Conduit had been inside the GNOME Wall for 2.20 then this discussion wouldn't be happening, or it wouldn't be me crying OMG, save Conduit!!. Perhaps the solution there is to break out the whip and see if Conduit can move inside the great wall? I think an important thing here is that some people won't want online.gnome.org. Personally, i might be tempted to use Conduit to sync them to an SSH account or a password protected area of a server I control. You're comparing apples to oranges. If the desktop has a feature to sync my private notes to a private directory, then that's cool and I'm all for it. Somehow I forgot that Tomboy had SSH sync already. Damn. Forget I said that... I'm not working on that feature, though. What I'm working on primarily *is* the server-side Tomboy app. The only way I am looking at touching Tomboy itself is to have a sync plugin that happens to sync to this server-side app, *instead of* a private data store. The private ssh server is still a configurable choice. The two features aren't the same or somehow interchangeable, they are two different, mutually exclusive ways to store your Tomboy data with different advantages. I do get that data store != web app - I think Backpackit.com was among the first DP's i touhced IIRC. So Conduit has a dataprovider. Tomboy has a sync plugin too. That's fair enough. As I said earlier, we are doomed to this kind of multiplicity-ness as long as we are outside the wall :-( By integrating Conduit people have that choice, and at the same time we don't waste time on multiple sync implementations. Whether Tomboy uses Conduit is a separate issue from my project, and whether online.gnome.org has a server-side app available, though, right? I mean, Tomboy already supports choosing your sync plugin. If we move the choice of sync plugin to Conduit, that's cool, but hasn't changed anything about the code I'd have to write. I agree with you. But I am keen to see the interface kept simple... I guess my problem is that we have OpenSync, we have Conduit, we have Tomboy. 3 separate syncing engines. My original e-mail was really aimed at seeing where we fit in. Is there room for 3 ways of syncing on one desktop? We are already working to make it 2 by working with the opensync people. Tomboy can't depend our code though :-( The situation in Tomboy today, or with Conduit, is that you can sync it to a private DAV/ssh filesystem. And what I'm looking to add is that you could also sync it with a web app that knows specifically about Tomboy, if you choose to do so. The situation in Tomboy today is that you can sync to a DAV/ssh/fuse filesystem, and that you are going to add support for OGO. The situation in Conduit is that you can sync to GnomeVFS, Backpackit.com (a web app not too far removed from (i imagine) the first few phases of your project), iPod Notes, Evolution Memos or any
Re: slab menu
Please constrain useless comments like this to private email. -Alex Alex Jones wrote: Let's face it, slab was conceived out of Novell's desire to make SuSE a drop-in for Windows. I don't think this is the direction we want to be taking GNOME, personally. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: slab menu
You guys should really check out how the Gimmie applet is doing things. Recently used apps are easy to find, as they're listed right next to the flattened menu categorisation Gimmie uses in the Applications pane. So there is very little impedence for apps not in the recent list. Favorite apps are easy to tag. You toggle the favorite button at the bottom of the pane. This causes the app to be listed in the All Favorites category at the top of the Computer pane. If you place the applet in a corner, the Computer menu and it's first category are the first to display when clicking in the corner. So you get some Fitt's law benefit when accessing Favorites. Not to mention that anything can be favorited for quick access in the same fashion as applications: documents, IM buddies, network shares, printers, capplets, tomboy notes, etc etc. It's pretty awesome. -Alex P.S. This is a resend. Hopefully mailman won't eat it this time. Calum Benson wrote: On Mon, 2007-02-05 at 13:02 -0500, JP Rosevear wrote: How is it slow to get to things vs a traditional hierarchal menu? My important apps are two clicks away - open menu - click. Hierarachal menus more clicks than that. Don't like the default list? Drag from the app browser and drop them on the menu. Much as we'd all like it to be untrue, that's still more customisation than many (most?) average users are either willing to do, or have the knowledge to do, or (in some cases) are allowed to do by their sysadmin. You should see the state of the Start menu on my wife's Windows laptop, it takes up almost the whole screen, and it's not even in alphabetical order :) But she says she has no interest in streamlining it, and wouldn't know how to anyway. Cheeri, Calum. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
remove tomboy dependency on gtkspell?
Hi, I've just been notified that I need to make support for GtkSpell optional (it's currently a hard dependency). Just want to verify this. -Alex ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: sticky-notes - tomboy conversion
Why clutter common parts of the UI with an action that people will run at most once? It will be triggered automatically the first time Tomboy is run for most people anyway (after Sanford's most recent change goes in). -Alex Matthias Clasen wrote: On 8/22/06, Sanford Armstrong [EMAIL PROTECTED] wrote: On 8/22/06, Matthias Clasen [EMAIL PROTECTED] wrote: So, can we please make the sticky notes import happen automatically and unintrusively at startup ? After all, we already replaced the applet itself without asking the user... This is in progress and will be in Real Soon Now. Of course, if the sticky-notes deprecation was premature, and sticky-notes will be back for another round in 2.16, then a manual conversion is more appropriate - but it could be more discoverable. How about replacing the Open Plugins Folder menuitem (which is of dubious usefulness anyway) by an Import Sticky Notes menuitem ? Or add a button to the Table of Contents dialog - which is the place where I would go to for my missing notes ? Such a button could be added only if we find existing sticky-notes configuration... 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 panel layout for GNOME 2.18?
Slab is a better system and GNOME should use it by default, IMHO :) -Alex David Nielsen wrote: tir, 22 08 2006 kl. 17:53 -0300, skrev theblues gnr: I don't think an usability test has ever been done with the current layout. At least I never heard of one. BetterDesktop seems to have done this, slab is part of the result of those tests. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Global keybindings in GNOME
If we do something like this, I think it's important to present the UI in a way which isn't overwhelming. Having a bunch of apps that I've never heard about and never run populating a huge list in the already-huge keybindings dialog would be undesirable. No real ideas here, just something to watch out for... -Alex Matthias Clasen wrote: On 8/6/06, Nigel Tao [EMAIL PROTECTED] wrote: 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? I had envisioned that this could be implemented by having apps install small xml files in a well-known place which contain a translated name/description of an action they want to make available via a global keybinding, plus a command to run in that case. Of course, bringing in D-Bus and other gizmos would crank up the coolness factor... 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: Global keybindings in GNOME
I don't see these two as being very different from a user's perpective. Given how long the list in the capplet is today, I already just guess when setting a keybinding there, and rely on the app to show me a conflict. -Alex Havoc Pennington wrote: Since bindings are a global resource really there are two options for avoiding conflict: - foist it off on users - when they install an offending app, a dialog comes up like this app wants to bind F12. the desktop has already bound F12 then the user chooses F11 instead and a new dialog is all such-and-such already has F11. try again! and so forth... not good. - have a centrally maintained list of global bindings that don't conflict ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Tomboy already does this, though the description it gives is pretty minimal today. What do you think it should say? -Alex Iain * wrote: Maybe on first run the Start Here note could pop up on screen and explain what it is. I dunno, but thats a discussion for the tomboy developers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Hi, Here's a status update on recent Tomboy happenings... I've applied a patch originally from Novell to use Tango icons and removed the possibly legally entangled Tintin icon. I've also just committed the patch from Sanford for the initial Sticky Note importer plugin. And I've merged a bunch of the changes from a working branch to HEAD to support the switch to Gtk# 2. I believe this removes all of the concerns (actually related to Tomboy) blocking addition to the desktop, but perhaps I'm forgetting something. -Alex, missing Tintin Sanford Armstrong wrote: On 7/24/06, Shaun McCance [EMAIL PROTECTED] wrote: If I did an upgrade[1] and Sticky Notes wasn't there anymore, I'd be pretty pissed. That's my data. It was probably important. And it's gone. Sure, I'll bet it's buried in a dot directory somewhere. I'll bet I could find it. I'll bet my mom couldn't. Just FYI, we have a plugin[1] that imports your sticky notes into Tomboy. We are still working on what sort of automatic import on first run behavior it should have. I think it's a fair bet that this plugin (or something similar) would be activated by default if Tomboy were replacing Sticky Notes in GNOME. Sandy [1] http://beatniksoftware.com/pipermail/tomboy-list_beatniksoftware.com/2006-July/001234.html ___ 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: Tomboy in Desktop
Hi, Novell has sent me their patch to replace the Tintin icon with a Tango icon, so the next release will no longer have it. -Alex Steve Frécinaux wrote: Jeff Waugh wrote: quote who=Jeff Waugh * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) IIRC, there was an issue regarding Tomboy's icon (it was Tintin's head, which was both ugly and copyrighted). Was this one addressed or does it still use the same icon ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Hi, To the first quoted point, I don't recall ever rejecting Sticky Note import. Quite the contrary, I've advocated that we use a first-run import wizard to aid migration. Serendipitously, in recent days, most of the major work for importing has been contributed by Sanford Armstrong in the form of a Tomboy plugin. Sanford's patch adds an item to the Tools menu labeled Import from Sticky Notes. But as this is perhaps not the nicest or most discoverable mechanism I'm trying to figure out how to best integrate this code for a nice experience. Comments welcome. To the second point, I have received very mixed response to the question of Tomboy's replacing of Sticky Notes. And we can see that mails to this list have expressed both points of view, with a slight bias towards the two coexisting (especially from those who actually use one tool or the other). I place myself in the coexist camp, mostly because the interaction models among the two tools are very different (again, Tomboy ain't sticky). A user who is used to Sticky Notes would be very confused if forced to use Tomboy, and vice versa. However, if the release committee believes that enforcing a single note-taking approach is what is best for the desktop, I think it makes sense to choose the solution which is novel, more scalable wrt the number of notes, less intrusive on user activity, supports richer note content, and which opens up possibilities for integration with other parts of the desktop. -Alex Jeff Waugh wrote: * Alex says that Tomboy doesn't replace Sticky Notes, he doesn't really want to migrate Sticky Notes data into Tomboy, and that Tomboy and Sticky Notes suit different use cases. * In my experience, users perceive Tomboy and Sticky Notes to fulfill the same (or similar) function. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Notes in Sticky Notes are modal meaning they are all displayed on the screen or they are all hidden. I currently have 307 Tomboy notes :-) -Alex Steve Frécinaux wrote: What about sharing the note storage between the two ? I feel like it's not possible for tomboy to use raw stickynotes data (since it has more information, like title and so on) but what about the other way round ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
I would love to write documentation for Tomboy, and fully intend to. But as my users have not requested it, and Tomboy's acceptance into GNOME is still totally up in the air for other reasons, I hope you can understand why I've held off on it in favor of other endeavors. -Alex Shaun McCance wrote: Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Alacarte will involve changes to the User Guide. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Respectfully, I don't agree. There is a big set of missing frameworks that stops rich interop in Gnome applications, and generally make applications much harder to write well. All other desktop platforms include at least a subset of these... * Document framework Provides document loading/saving/printing/etc abstractions, window/tab management, automatic recently used, scripting hooks, etc. * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. * Rich Extension/Plugin framework Common UI for installing/removing plugins and checking for updates and downloading, common hooks for menu/toolbar integration and UI event integration. * Undo framework Almost no applications in Gnome support good Undo. Should provide both reliable desktop-wide interaction for text widgets as well as at an abstract object level. * Rich DND/CopyPaste framework Undocumented DND targets, poor support, and manual data parsing abound in our applications. Could provide structured data interop to make doing this loads easier. * Persistence framework Saving and indexing application-internal data, optionally exposing to search engines like beagle. Each one of these is a really large amount of work that doesn't exist at all today, with various bits being implemented from scratch in every application. -Alex Federico Mena Quintero wrote: The GNOME platform is pretty much *done* at this point from the viewpoint of what more code do we need?. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
The thing is that the user models are very different. If a sticky notes user is accustomed to always seeing his notes on his desktop, all at the same time, if after an upgrade his notes are locked away in a menu with no easy way to get them all to display again, he might be confused and probably annoyed. -Alex Murray Cumming wrote: In my opinion, having both would be a very odd duplication of functionality, and would be confusing for users and distros. What can sticky notes do that Tomboy can't? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
I think using Star-Bellied Sneetches and Plain-bellied Sneetches would work well, if you're in to the whole brevity thing. -Alex Jason D. Clinton wrote: On Mon, 2006-07-17 at 10:33 +0200, Andy Wingo wrote: On Sun, 2006-07-16 at 23:33 -0500, Jason D. Clinton wrote: Anti-Mono folks generally [...] think that high level languages should only be used for prototyping (the benefits of RAD don't outweigh the cons). Some people have said this, but I don't think all people uncomfortable with mono would agree. I should have replaced every occurrence of Pro-Mono folks with some people whom at some time in April, May or June argued for including Mono in GNOME in some way and Anti-Mono folks with some people whom at some point in April, May or June argued against including Mono in GNOME in someway ... but then it would have been impossible to read. I would like to remind them that gnome-games, long included by default on every Linux distribution, depends on Scheme (the guile bindings). AFAIU it only depends on guile, not the guile bindings to the gnome stack. Yes, you are correct. ___ 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: Killing the splashscreen for 2.16
Seconded. -Alex Soeren Sandmann wrote: I would like to turn off the login splashscreen by default, for the following reasons: ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
I'd rather see SoC contributors working on syncing multiple computers, or shared notes, or even bulletpoints (which could benefit all GtkTextView using applications). I'm not sure how to get the ball rolling on SoC though. What can I do as a maintainer/possible mentor? -Alex Nigel Tao wrote: 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
Hi, 1) This bug could probably use some feedback from you, if you are still seeing it in the newest version. 2) This is an artifact of depending on Gtk# 1. Work to remove this dependency and switch to Gtk# 2 is underway on the tomboy-0-4 CVS branch, the next major release branch. Please give it a try. 3) The evolution mail linking plugin introduced in the latest release is quite buggy, it was included to get some exposure and testing. 4) Can you provide some startup timing information so we can figure out where this time is spent? Thanks, -Alex Nate Nielsen wrote: Sriram Ramkrishna wrote: So I'm seeing that everybody is up for Tomboy as part of the desktop. Yes? I use Tomboy. However I think that Tomboy is missing several things I've come to expect in modern GNOME apps. As a developer I can put up with certain deficiencies, but these will be more frustrating to users: * Doesn't respect keyboard layouts. In particular Tomboy is almost useless those who type with a dvorak keyboard layout, and I'd imagine other locale's layouts have problems too [1]. * Doesn't use the new file chooser [2]. * All sorts of strange copy and paste behavior, usually when related to links. Sometimes I feel like I'm fighting Tomboy, and struggling to keep my note sane. Some examples: [3] [4] * Takes a really long time to start up. 8 seconds for me. IMO Tomboy would need a good deal of attention and polish before released as part of GNOME. Obviously these things could be fixed after it was marked for inclusion. However, in the past this would mean that the maintainer was asked to polish/complete and propose it again for the next release. Cheers, Nate [1] http://bugzilla.gnome.org/show_bug.cgi?id=171075 [2] http://bugzilla.gnome.org/show_bug.cgi?id=336507 [3] http://bugzilla.gnome.org/show_bug.cgi?id=330965 [4] http://bugzilla.gnome.org/show_bug.cgi?id=330964 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
HELLO?! Check 1-2-3? The discussion *was* about Tomboy. An small app I wrote that people like, and which could benefit from adoption in GNOME. Thanks for throwing any chance for productive discussion out the window. Maybe I'll wait until 2.20 to propose again. Maybe... -Alex Luis Villa wrote: On 4/20/06, Murray Cumming [EMAIL PROTECTED] wrote: On Thu, 2006-04-20 at 22:38 +0200, David Neary wrote: Hi, Elijah Newren said: But, a more important question: We currently only allow apps using the python bindings into the desktop. Is this true, or is it just because no-one's ever asked? We've had extensive discussions about it on this list. Python is the only one that almost nobody objects to, and a lot of people would prefer us not to use too many programming languages in the official Desktop modules. But luckily, not everything needs to be in the Desktop. I certainly wouldn't want to add the political, technical, and strategic baggage for just a note taking utility. But lets be honest here. This discussion isn't about tomboy. We need built in search; we're getting some of our best reviews in ages because of our (currently optional) built in search: http://www.eweek.com/article2/0,1759,1948842,00.asp?kc=EWRSS03129TX1K616 If this discussion is about any app in particular (it probably shouldn't be, but it probably will be) this discussion is really about beagle, not tomboy. Luis (why, what a big pink elephant you have in your pants^Wroom) ___ 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: Tomboy in 2.16
Ya, that makes sense to me. I'd like to move towards a pluggable storage backend approach anyway, to support network storage or shared notes, so an e-d-s backend could be an option as well. It seems like this issue shouldn't block Tomboy's inclusion though, given that e.g. stickynotes doesn't store in e-d-s either, and I've not received any requests for tomboy/e-d-s storage. A future goal to unify storage sounds good to me, once people start using Tomboy and Evolution notes both. -Alex Rodrigo Moya wrote: On Thu, 2006-04-20 at 12:10 -0700, Alex Graveley wrote: Two questions: 1) Can you explain the actual user-benefit to keeping Tomboy notes in e-d-s? the user can use whatever frontend, but the notes will be the same in all applications. Isn't that a benefit? No need to export/import/look for weird .dotdirs where the files were saved last time a specific frontend worked, etc, etc 2) Is moving Tomboy to use e-d-s going to be a requirement for inclusion in Gnome? I don't think so, but it would be a good thing ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
Two questions: 1) Can you explain the actual user-benefit to keeping Tomboy notes in e-d-s? 2) Is moving Tomboy to use e-d-s going to be a requirement for inclusion in Gnome? -Alex Rodrigo Moya wrote: On Thu, 2006-04-20 at 17:27 +0530, Harish Krishnaswamy wrote: Embedded GTKHTML in the calendar/memos/tasks component is under works. It should be available by the second or the third dot release in the current dev cycle :-) And yes, I think the HTML approach would be the shortest-path for the integration too. great! Then let's move all apps to e-d-s API. Any objection? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
Seriously. There *are* those of us out there actively working towards 3.0. We'd get there a lot quicker with more help. http://beatnik.infogami.com/Gimmie -Alex Jeff Waugh wrote: Write code. Make things happen. That's ultimately what matters. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
Nah, you just need stable URLs and a DBUS interface, which Tomboy already has. -Alex JP Rosevear wrote: I'm not totally sure its worth it. But if we want to talk about first class objects and tagging there has to be some storage mechanism for the meta data (e-d-s, beagle, tracker, something else). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
I think including Gtk#2 in the binding set is a prudent idea, but we should ask the maintainer if he is interested. Mike? -Alex Vincent Untz wrote: Hi Alex, Le mardi 18 avril 2006 à 14:33 -0700, Alex Graveley a écrit : Given that Tomboy is the probably the smallest and therefore the most digestible of the new crop of Mono-based Gnome applications, I think the time is right to discuss inclusion. Thanks for proposing tomboy! My main question is about the Gtk# bindings: should we include them in the bindings set before including an app? Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
Hi, I've never really felt comfortable with the linked-square icons, which is why the Tintin logo has been around for so long. Though, at this point, I suspect the linked-square is reaching de-facto status. (I would like to note that I've never received a patch to switch the icons, even though every distro is using one.) I raise the question of stickynotes in my original mail... I am somewhat indifferent to the decision. I do think forcing stickynotes users onto a completely different interface is a bad idea, especially one lacking the features they expect from stickynotes (namely the stickiness). An import wizard the first time tomboy is run might be a better option. -Alex Rodney Dawes wrote: On Tue, 2006-04-18 at 14:33 -0700, Alex Graveley wrote: Tomboy is already a well-behaved Gnome application, but several tasks would need to be completed before inclusion: * Using jimmac's trademark-free icons by default. The standard sticky notes icon, or the linked notes icon? It seems that despite the fact that the linked notes icon is more like notes, it is unclear as to what is actualy in the icon, because the concept of linked notes is somewhat hard to comprehend for users. We all know that they are linked, but perhaps this is just a technical detail that we should not be conveying in the icons and such. It's an interesting feature, but it's not really the entire selling point that we should be using for tomboy, I think. Jakub has drawn some standard sticky-notes style icons, which I think probably let users understand what tomboy is, much better. Also, if we do make tomboy part of the desktop, does that mean we should drop the notes applet from gnome-applets? If so, does that mean that we will be losing data for some users? Can tomboy migrate that data over, so that we don't just end up losing the notes for those users? -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
All the more reason to get some more eyes looking at it! -Alex Federico Mena Quintero wrote: On Tue, 2006-04-18 at 14:33 -0700, Alex Graveley wrote: Tomboy is a desktop note-taking application for Gnome and is bundled by many major distributions. I think it counts as a popular and worthwhile software. Should we bite the bullet and add it to the Gnome desktop officially? I'm all for this. Tomboy now has all my plans for world domination. But Tomboy takes 11 seconds from the time it gets exec()ed until it actually registers its OAFIID. Some profiling love is in order :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keyboard usage on some Gnome windows not working
Speaking of Emacs, one of my favorite features has always been when executing an M-x command that the minibar flashes the shortcut sequence you _could_ have used for the same task. I find that I learn the commands I use most often[1] this way. If I know the command it's because I've seen it flashed in concordance with actually performing that action 15 times or so. I would love to play with a system that only revealed accelerators somehow after I used individual commands a few times[2]. HIG-defined accelerators could be shown all the time, since they should be common across apps. The idea being that less visual clutter, and a smaller set of well-known and trusted keyboard commands would be more friendly and cause less dithering. -Alex [1] Which is an ever changing set. [2] For instance maybe revealing them slowly using an alpha blend of the menu item accelerator label which becomes less transparent the more I click on the menu item. Or using notify bubbles. Elijah Newren wrote: On 10/20/05, Shaun McCance [EMAIL PROTECTED] wrote: On Thu, 2005-10-20 at 08:49 -0200, Matthew Thomas wrote: No, there aren't. http://asktog.com/TOI/toi06KeyboardVMouse1.html I see there is some research showing that the keyboard is faster for common commands http://ad-astra.ro/research/view_publication.php? publication_id=1508lang=en, but that wouldn't include access keys unless you were encountering particular dialogs or alerts very often. When Tog says The stopwatch consistently proves mousing is faster than keyboarding. I'm curious what he means. I'd really like to see what tests were performed and what the actual results were, rather than a one-line synopsis. As a mathematician, I'm suspicious of pretty much any one-line statistical synopsis. Imagine this test: Agreed, I thought the AskTog article was being overused and mis-applied in a number of cases, so I at one point went and read through the relevant article pretty closely, plus related ones and comments. Unfortunately, it's been a long time, but from what I recall, the tests were done in the 80's or so and users were not yet familiar with shortcut keys (i.e. no muscle memory to bias the results). In the explanations he provided for the mouse being faster than the keyboard, he said the reasoning was something along the lines of users need to do all kinds of shape recognition to recognize what the hotkeys are (including finding which letter is underlined, I presume) and then translate that into a letter, and then get their fingers to strike the right key. He did specifically say, perhaps in another article, that having certain shortcuts would save time over the mouse for very common operations (cut, copy, paste...; also, on a related note that I found amusing, he argued that command-p should be reserved for making text be plain (as opposed to bold or italic) instead of using the key for printing on the grounds that computers were almost exclusively used as word processors and making text plain was a far more common task...). Now, the big question is--how many have memorized the shortcut keys for certain dialogs that appear? Unless they show up often, users probably haven't memorized them and thus using them for those dialogs may actually be slower. Also, another interesting tidbit: A number of years back, I went for about 2 years without using emacs (or computers much at all, though that's beside the point...). It was kind of painful when I started using emacs again, because I couldn't recall what any of the necessary shortcuts were and didn't have a nearby listing of them. If someone asked me how to save my document, I would not have been able to tell them what the key sequence was. But, I started typing along anyway and at some point, nearly out of habit (I guess I don't trust autosave and have developed this habit of hitting the save sequence early and often), I found myself pushing my fingers down in a certain pattern that I hadn't forgotten--I quickly pressed the lower left key on the keyboard with my pinky and held it down and pressed two keys in succession with my index finger of the same hand. The sequence I happened to type was Ctrl-X, Ctrl-S. I then went whoa, so that's how you save, cool. I had remembered where the keys were when I was in a rhythm, but not what they were. For the vast majority of the emacs shortcuts, I had to go look them up and learn them again, but for this one and a few others, I relearned them merely by using them in this only-know-how-to-move-my-fingers when not really thinking about it. Cheers, Elijah ___ 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: Moving to *Avahi* over howl
Callum, Regarding #1, avoiding a implementation switch in your code. This is a side-effect of the implied neccessity of #2. Regarding #2, swapping out implementations. This is the only concrete reason you give for needing an abstraction, and the only reason you give for needing it is Gnome-on-OSX. Regarding #3, better integration with Glib/GObject. Avahi uses a similar library split to DBus to support this. It isn't a problem. Please, please tell me Gnome-on-OSX is not the only reason we are so scared to commit to Avahi. -Alex Callum McKenzie wrote: On Thu, 2005-09-15 at 20:07 -0700, Alex Graveley wrote: Does anyone have any sort of convincing argument as to why an API abstraction in this case is *needed*? (I like abstractions is not an argument.) Here are some arguments: 1. So I don't have to have a series of #ifdef statements to support various implementations. 2. So we can swap out the preferred implementation. 3. So we can integrate it into the normal glib way of doing things (signals, gobjects, etc.) regardless of which implementation is used. The counter-argument is of course why don't we just pick one. Then obviously you don't need to abstract the API unless the chosen API doesn't fit in well with normal GNOME code (point 3). One of the main reasons I accepted the patch for bonjour support when I already had howl support was because it makes more sense, when running the MacOS X port of GNOME, to use the native library. So that's one reason why not. The other reason I see for supporting multiple implementations is that it isn't yet clear what is the best way to go. If it was clear I don't think this thread would have started [1]. - Callum [1] I predict that whichever implementation is first supported by the wrapper will quickly become the default because it has the nice abstraction and no one is afraid to use an abstraction, thereby removing any need for an abstraction because we have effectively made our choice. This is of course pure cynicism and not an argument for any particular course of action. ___ 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: Auric Implemented (mostly!?)
I would suggest just stealing the Tomboy code for this until something better comes along. See http://cvs.gnome.org/viewcvs/tomboy/libtomboy/tomboykeybinder.[ch]. Also, another suggestion would be to always search Beagle in realtime and include the results inline in addition to all the other engine's listings. This could make deskbar a ``one-stop finding shop'' ;-) -Alex Nigel Tao wrote: * Add a key binding to jump in it, like beagle does with F12, maybe it already exists, i couldn't find it. A global keybinding would be sweet, but I'm not sure of the best way to do this right now: http://mail.gnome.org/archives/desktop-devel-list/2005-June/msg00163.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
For the record, I think such a widget would be useful for almost every document-based application. Such a widget should be robust enough to handle simple snapshot-the-viewport behavior, and overridable to support more advanced things like outline-shadowing for longer text files used in some IDEs. -Alex Luca Ferretti wrote: Il giorno dom, 21/08/2005 alle 00.50 -0400, Jonathan Blandford ha scritto: Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project Ridley. GOALS: The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy. They have an unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted around (such as libegg) or would benefit by being in GTK+ (libgnomeprint and libgnomeprintui.) Not well fitting with this disclaimer, but are any interesting widget in GIMP to include in Project Ridley? For instance the small cross-arrow between the vertical and the horizontal scrollbars, used to scroll the image when zoomed in showing a thumbnail, could be useful for other GNOME application related to image (eog, gthumb, f-spot) and document (evince) viewing. Could someone explore and report about GTK+ widgets in GIMP sources useful for other applications? ___ 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: Removing xrdb for 10% startup win?
My gut reaction is that you should disable it now, and reenable/cache xrdb if user response is negative. This way you could focus on other ways to speedup the desktop launch, possibly providing other major wins. The Return on Happiness (ROH) is much higher for speeding up 95% of our users a non-trivial amount, versus the 5% who would have us maintain the status quo of xrdb. -Alex Lorenzo Colitti wrote: Hi, For my Summer of Code project (mentor: Owen Taylor) I am working on improving gnome startup time. Proof-of-concept work on gconf has already succeded in reducing boot time from ~35 to ~20 seconds, showing that there is room for improvement. Moving down the list of top culprits, my benchmarks show that xrdb (and the cpp it spawns) to be one of the worst, and indeed symlinking xrdb to /bin/true results in a ~10% reduction in startup time. xrdb is called by gnome-settings-daemon in order to make the colours of X applications match the standard GTK theme and to merge in user settings from .Xdefaults, .Xresources and .gnome2/xrdb/* : http://cvs.gnome.org/viewcvs/gnome-control-center/gnome-settings-daemon/gnome-settings-xrdb.c?rev=1.5view=markup I was thinking of implementing a cache for xrdb, but in discussion on IRC some people also suggested that xrdb should either be turned off by default (using a gconf key) or should be made less flexible, e.g. by not supporting #define statements in user files. Since there's no point in me implementing a cache if this code is going to get turned off anyway, I'm posting this here for opinions. The argument for removing xrdb altogether is that users that are putting #define statements in .Xdefaults or .Xresources are (a) rare, (b) probably non relying on gnome to call xrdb for them, and (c) savvy enough to fix the problem if they are. Thoughts? Should xrdb be turned off by default? Cheers, Lorenzo ___ 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: gtkspell (was Re: Announcing: Project Ridley)
Jody, How complete is your undo stack? Does it handle undoing style changes? Redoing rich content pastes? Inserting images? Does it handle aggregating multiple key presses or deletes into words that can be undone as a unit? -Alex Jody Goldberg wrote: On Fri, Aug 26, 2005 at 02:03:00PM -0400, Bryan Clark wrote: I don't have a problem me tooing this request, since I think I've been asking for spell checking for all text-entry widgets for the past two years as well as a richer textview widget. IMHO we should have a textview widget that is good enough to pretty much replace GtkHTMLEditor, with undo/redo and easy to add font, style, and color widgets for text areas. Good spell checking is just another part of good text input. We've got several of the desired widgets/gtkactions in goffice now. - font face combo - alignment combo and widget (including rotation) - colour combo - undo/redo stack - image file selection I'd also like to see some of the evince/MS Office XP widgets show up - the sidebar - firefox style search entry even something as simple as a zoom combo could be standardized. There are a plethora of document-centric activities that are being replicated. Given the plethora of apps with some forms of drawing - gimp - inkscape - gnumeric/abi It's also possible to make a case for things like - gradient selectors - line width/style selectors - pattern/stipple selectors ___ 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: gtkspell (was Re: Announcing: Project Ridley)
I'm all for spellchecking in Gtk, but GtkSpell has been nothing but trouble for me in Tomboy. It still doesn't handle multiple textbuffers sharing a tag table (which means that rich copy/paste doesn't work), and has some serious memory leaks (though this may be due in part to pspell). -Alex Mike Hearn wrote: Yes, it's yet another me too post, this time for gtkspell. Spelling checker support is widely used in many apps, and from my POV is a huge pain because gtkspell is a very common failed dependency for autopackages. We provide tools to make weak linking against this library simple but a few projects for whatever mysterious reasons they have refuse to use them. Being able to guarantee the presence of GtkSpell by depending on GTK+ would be wonderful. Last time I asked about this, Owen indicated he didn't think it belonged in GTK+ but maybe this Project Ridely means a change in policy? thanks -mike ___ 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: [PATCH] notification hints for weather applet
Seems like a simple heuristic could be employed here, to not be overly intrusive and still very useful... Define a set of extreme events, such as rain, sleet, snow whatever. If and only if the weather changes from a non-extreme event to an extreme event, then notify. Use a time threshold (like say 2 hours) between notifies to avoid annoying the user, and cover the case where rain/no-rain is toggled repeatedly. Or you could just play a thunder sound when it starts raining ;-) -Alex Rodrigo Moya wrote: On Thu, 2005-08-25 at 11:53 +0100, Calum Benson wrote: On 25 Aug 2005, at 11:01, Rodrigo Moya wrote: ok, committed original patch to HEAD. I didn't read the code, but is this really a patch that notifies you every time the weather changes? If so, I have to say that sounds utterly crackful to me... especially if you're monitoring the weather in Ireland, bloody thing would never be off the screen :) What would it actually be useful for? To tell you when to run outside and take the washing in? it's off by default, so no need to use it if you don't like it. It0's just a non intrusive notification of a change. whatever you use it for is up to you :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application/System Tools vs System/Administration
Hi, I think the Windows capplet should be removed from the main Gnome control-center packages, and spawned off into a GnomeUITweak package that is part of the Fifth Toe or similar. Call me a nut, but I think the CDDB, Menus Toolbars, and Multimedia System Selector capplets should as well. I've been using GNOME since before 1.0 and I never use these things, and can't even perceive of a need to. Why are they cluttering up my life? People who know or care what these capplets do are such a small, hyper-advanced set of users that I think asking them to install a separate package is not a large request. -Alex Danilo Šegan wrote: Yesterday at 21:36, Larry W. Virden wrote: On Thu, 2005-07-07 at 07:43 -0700, Rob Adams wrote: and focus-follows-mouse is just silly really, despite the fact that I use it :-) ). Sorry - but focus follows mouse is so far from silly that the word loses its meaning in context. Let me remind everyone that this is a discussion about showing this as a preferences capplet. To illustrate my point, I use the following: - focus follows mouse - double clicking titlebar shades the window - I don't have a taskbar anywhere on my desktop (I have a window list menu button though, but I rarely use it: I have a big [3x4] number of workspaces) - I don't have minimise on my titlebar (I just have close button on the left side, and general menu on the right—I should probably remove the menu one as well, since I rarely use it, and it's available with a right-click on the titlebar as well) To get to all of these, I need to use gconf-editor anyway. I didn't even know you could set some of these through a Windows capplet. I'm not yet ready to become your average home user (to use all the defaults), so I appreciate having these options, but I really don't care about the Windows crapplet. Cheers, Danilo ___ 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: Control center and capplet merging
I think merging Font into some sort of Appearance capplet makes a lot of sense. I think Appearance is a perfectly discoverable name for this kind of setting. Merging Font into an Appearance applet would open up the ability to have an actual Font capplet, that launches fontilus. Installing and managing fonts is unexposed in the UI currently (afaict), unless you know to Ctrl-L type fonts:// in a nautilus window. Having an entry point to fontilus would actually be useful to me after the first 10 minutes of using a new desktop install, unlike the desktop/terminal/window-manager Font capplet. -Alex Luca Ferretti wrote: Il giorno lun, 27/06/2005 alle 17.08 +0100, Calum Benson ha scritto: On 27 Jun 2005, at 10:07, Luca Ferretti wrote: I did have no time to add comment on wiki page or open relevant bugs, but IMHO merging Theme and Fonts capplets is not a so good idea. One advantage it would have would be for accessibility... it's pretty common to want to change both together if you need a High Contrast Large Print theme, for example. (And personally, the first thing I do when I install a Linux machine is to change both the font and the theme, and then I pretty much never touch either of them again, so I've always wanted them in the same dialog anyway...) This is a personal taste, and I suppose you are an experienced computer user as everyone on this mailing list. The last time i opened the Font capplet to change something was... humm.. 2 years ago... IMHO it's better to keep them separated for average (and sub-average) users, so they can simply discover them. Reading Appearance in the Preferences list, do you think everyone can figure that it's the place to tune fonts? I see that a separate Accessibility capplet is proposed as well, though, so perhaps this wouldn't be an issue any more anyway, depending on its precise contents. (Although I'm not sure if capplets that affect values in other capplets are such a great idea either, but that's probably a separate argument...) Well, for this kind of needs i was thinking about something like the attached mochup[1]. Of course it overlaps the Theme, Font and Background capplets, and sets more keys with a single widget[2], but if you need to setup an environment for impaired users it's quick and simple. 1. Strings suck, I know 2. i.e. I believe that activating the Using computer I've difficulties with font size option, the system should use Sans font at the same size everywhere (window border, desktop, applications..) ___ 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: ANNOUNCE: Deskbar Applet 0.3 (keybindings)
So what do I tell Tomboy users who complain that its global keybindings don't work from the myriad other WMs out there? At least when I do the X keybinding myself it mostly works from everywhere. -Alex Havoc Pennington wrote: On Fri, 2005-07-01 at 17:23 +0200, Erwann Chenede wrote: 3) get ride of one of the implementation of the custom keybindings feature (either in g-s-d or metacity). 4) integrate all keybindings in one place. This would be a bit more complex to get the architecture right. My view is that global keybindings should all be in the WM, fwiw, and for the most part we've taken that path I think. e.g. the panel-related ones are in metacity and send a message to the panel. I didn't realize this went into g-s-d or I probably would have whined about it ;-) Havoc ___ 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: ANNOUNCE: Deskbar Applet 0.3 (keybindings)
Well, we can enforce no conflicts without going through a third party, right? The UI enforces no conflicts, and the library checks that a keybinding is not already taken at bind time (allowing the app to prompt the user if it is). It isn't as though a third party gives any better form of conflict avoidance... apps can still bind using X manually, which is what is done today. -Alex Mark McLoughlin wrote: On Thu, 2005-06-16 at 11:57 -0700, Alex Graveley wrote: I think the global binding problem can be solved by just designating a GConf path that apps install a keybinding action into. Then create a library with tomboykeybinder.c that apps call into with the GConf paths they are interested in. The library reads the GConf binding keys for the app and registers the X root window event handler. Hold on, isn't the main issue here that you want a single X client to be responsible for all the global keygrabs in order to avoid conflicts? A convenience API seems kinda secondary ... (We fixed this in the panel by moving the shortcuts to metacity and adding a ClientMessage protocol which metacity uses when the shortcuts are invoked) Cheers, Mark. ___ 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 (keybindings)
Hi, So my initial keybinding implementation tried to use metacity's command GConf keys. It's really gross in practice, since every time at startup I had to iterate the keys and determine if the default bindings exist, and re-add them if not. Also, the number of commands is bounded. I don't think we can rely on using D-BUS in the core desktop just yet, and we don't need to for this... I think the global binding problem can be solved by just designating a GConf path that apps install a keybinding action into. Then create a library with tomboykeybinder.c that apps call into with the GConf paths they are interested in. The library reads the GConf binding keys for the app and registers the X root window event handler. The library can handle processing the events and updating the X bindings whenever the GCconf keys get changed. Then you just have to expose the GConf tree through gnome-keybinding-properties. This makes things a lot easier to debug and there is no overhead if an app with global bindings is not running. -Alex Nigel Tao wrote: Alex Graveley wrote: I think it is a bad idea to make the global keybinding more accessible to apps... really there should be a central API that integrates with GConf to store keys sequences and command actions which integrates with gnome-keybinding-properties (which has a static action list today). This would avoid global keybinding conflicts and allow altering them in a single place. I was thinking... metacity already allows binding a key combo to an arbitrary command. It's not exposed as a GUI (yet...?), but you can do it through gconf keys. As a hack, I could piggy-back on metacity's global keybinding behavior, and the triggered command could be a little script to raise a D-Bus signal. My applet would respond by requesting focus. Having said that, I haven't looked at D-Bus and its API at all. Is this feasible? Is D-Bus the most appropriate way? Should this be rolled into gnome-keybinding-properties in general (i.e., have a raise signal %s or even a plain arbitrary command as a bindable Action)? thanks, Nigel. ___ 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: Evince as universal Viewer
Can we please hear the opinions from the maintainers of eog and evince, as to how they feel about one doing something for which it was not designed and the other being essentially deprecated? ... hair trigger away from delete thread ... -Alex On Apr 19, 2005, at 7:25 AM, Steven Garrity wrote: There's a brief discussion on one of the Fedora lists about how Eye of Gnome relates to gThumb. The conclusion is the usual one, and it makes sense: eog is the quick-to-load simple one-off image view, and gThumb is a more powerful image/photo browser. Makes sense. Someone mentioned Evince in the discussion and it made me wonder: should Evince replace Eye of Gnome as the universal Viewer app on Gnome. It already seems to support the basic image formats (jpeg, png, etc.). It also loads relatively quickly when opening a single image, and loads without the sidebar for formats without pages - so it has the look/feel of a simple/fast viewer app. In the version I'm running (0.1.9), the zoom controls don't seem to work on non-pdf files (jpeg, png, etc.), but I'm sure that could be fixed. I don't think there is really anything wrong with Eye of Gnome, but it might be nice to have *one* simple document/image viewer, rather than one for PDFs and one for other image formats, when they are so close in UI and core functionality. Not that this makes it the right choice, but for reference, this is what Apple does with their Preview application. Any thoughts? Thanks, Steven Garrity ___ 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
