Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
Hi, Steve Frécinaux wrote: Martin Ejdestig wrote: On Fri, 2006-10-20 at 13:11 -0400, Rodney Dawes wrote: The menu thing looks like the Mac menu, but doesn't behave anything like the real thing does on Mac OS. And the slab thing looks like Windows' start menu but doesn't behave anything like the real thing on Windows. Or did I miss something? :) Note that I'm not using MacOS, nor am I using Windows. I'm perfectly fine with the current gnome-y menu applet and don't want to see it replaced, that's all. I don't have a huge desire for change either. We seem to change the menu layout in pretty much every GNOME minor release that we've created. That's churn every 6 months. What makes you think that slab is any better? How long has it soaked in a Novell release? [or is this an excuse to avoid having to maintain code specific to Novell? - a 'yes' answer is fine, I can appreciate that desire...] Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
On Mon, 2006-10-23 at 20:46 +1300, Glynn Foster wrote: Hi, Steve Frécinaux wrote: Martin Ejdestig wrote: On Fri, 2006-10-20 at 13:11 -0400, Rodney Dawes wrote: The menu thing looks like the Mac menu, but doesn't behave anything like the real thing does on Mac OS. And the slab thing looks like Windows' start menu but doesn't behave anything like the real thing on Windows. Or did I miss something? :) Note that I'm not using MacOS, nor am I using Windows. I'm perfectly fine with the current gnome-y menu applet and don't want to see it replaced, that's all. I don't have a huge desire for change either. We seem to change the menu layout in pretty much every GNOME minor release that we've created. That's churn every 6 months. What makes you think that slab is any better? How long has it soaked in a Novell release? I've just tried using slab for a couple of days. It's very nice looking, but I don't think it provides anything more than what we have already. Its search feature ties into Beagle (we have Deskbar), it has NetworkManager support (we a tray applet), and its menu system leaves a lot to be desired. If the application you want is a favourite (of which there can only be so many), it's great. But when you want to administer your system, or run a different application, it's rather a different story, and you have to open up a clumsy program that then stays in memory for the rest of the session. Furthermore, it doesn't have the lovely Places system. Until the more applications problem is sorted out, I don't think it should be the default, as it would be a step backwards in terms of usability. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
On Sun, 22 Oct 2006, Sri Ramkrishna wrote: Date: Sun, 22 Oct 2006 13:48:46 -0700 From: Sri Ramkrishna [EMAIL PROTECTED] To: [ISO-8859-1] Germ�n Po� Caama�o [EMAIL PROTECTED] Cc: Rob Adams [EMAIL PROTECTED], desktop-devel-list@gnome.org Subject: Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18 I'm in total agreement here. I've used the slab menu which is included in Ubuntu. For those who want to make useful comments about slab as it compares with the other menu setups can apt-get install gnome-main-menu on Edgy. My personal feeling is that it does seem kind of slow. I find it hard to find applications when using the application browser. it's the same as windows. I understand there was user testing done but I would think that this is a big departure from the windows interface Were there any ergonomics or click tracking tests done on Slab? If this was used in GNOME it would be hard for those who use GNOME daily (as I do) to switch gears at first to using this interface. Perhaps windows users would appreciate the switch but I think regular GNOME users might find it a little hard to change. My feeling - I do not have testing facilities at my disposal - is that the old menus have very clear and blocky target areas and slab not so much. Ergonomics seems the more plausible explanation for experienced users having difficulties getting up to speed. Personally, if it looks like that people like the change I don't mind as long as we have a backwards compatible way to use the old menu system. Just because you change it doesn't mean you can't continue using the old way for those of us who have learned to use GNOME in that way. This also creates problems for systems administrators when you change UIs as it requires re-training for it's users which costs time and money to use the new system unless you can provide a method to let users migrate to the new system over time. I do hope serious consideration will be given to providing a stable experience for existing users and migration. It would be nice if proposed modules could be included in odd numbered releases without first fully accepting it so as to help when it comes to testing and evaluation, but I suppose Garnome (and Jhbuild?) largely take care of that. -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
On 10/23/06, Alan Horkan [EMAIL PROTECTED] wrote: It would be nice if proposed modules could be included in odd numbered releases without first fully accepting it so as to help when it comes to testing and evaluation See also http://mail.gnome.org/archives/release-team/2006-October/msg00024.html; seems like a good idea in need of someone to kickstart it. , but I suppose Garnome (and Jhbuild?) largely take care of that. and often distributors. jhbuild tends to do it as part of a meta-proposed metamodule (not included in meta-gnome-desktop, the default build target), though it tends to be forgotten and not updated for long periods of time. GARNOME is probably much more on top of the ball, as usual. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: User Documentation Requirements
On Thu, 2006-10-19 at 18:45 -0500, Shaun McCance wrote: I would like to propose requirements on maintainers of user-oriented modules (that is, those modules that need user documentation). As a programmer and maintainer, I don't think these introduce an undue burden. And as a documentation team member, I think they can help our writers significantly. For those who don't keep archives or have broken threading: http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00232.html Are there any further thoughts about this? Since I think there is constant confusion about requirements, I'd like to work on the pages here: http://live.gnome.org/ReleasePlanning/ModuleRequirements What I would like to do is put the requirements into five pages: common, new modules, applications, platform, and bindings. I'd like these pages to reflect everything we expect of maintainers. And then we should link to this page from, well, just about all the maintainer-oriented pages. Objections? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
On 10/20/06, Diego Escalante [EMAIL PROTECTED] wrote: but I was annoyed by how the application and configuration browser were ALWAYS running and eating about 100Mb of RAM. It's not an issue for me thanks to my Gig of RAM but for someone with less RAM it can be a killer problem. Is this fixed?. Looking at my system, both apps are using ~ 9meg. Maybe it has been fixed. My first impressions - It fits the way I work better, I have lots of apps installed that I rarely use, and only a handful that I do use regularly. I've dragged them into the menu as Favourites and its quicker than hunting through menus for them. It does highlight how badly some (most?) apps .desktop file descriptions are screwed up with the tiles looking like Epiphany Web Brow... Web Browser Cowbell Music Orga... Music Organiser If the generic description wasn't included in the Name, there'd be a lot less ... going on. Clicking on the Hard drive info brings up gnome system monitor, which doesn't really have anything nice about the hard drive...maybe running the disk cleanup tool in gnome-utils. The icon of the hard drive could have a nice little pie chart thingy, like http://ramnet.se/~nisse/diverse/temp/disk-space.png The Network thingy says Connected: Lin... does it need the Connected: bit, if it was left out, I could see more of my network name Having Places/Bookmarks would make it very useful. I like the use of colour to differentiate areas, I think we should do more of this in GNOME. And if it's replacing menus, I think it should replace both menus. We dont want menus to be the new clocks. iain ___ 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
Hi all, Today I was demo-ing KDE at the Systems in Munich and the GNOME presenter across from me in the GNOME booth told me about this discussion [1]. Since I'm the developer of Strigi [2] it interested me and I would love to contribute to this discussion. Also, I believe this discussion is of interest to the KDE developers, since KDE is also in need of good desktop search tools. Therefor, this mail also goes to kde-core-devel. First off, let me say that I'll be going slightly off topic by not only discussing inclusion of search engines into GNOME but also cooperation between the current alternatives. Both of these aspects have been talked about in this thread and I'd like to add to it from the point of view of yet another desktop search tool. But first let me introduce Strigi. Strigi is a desktop search tool that has many similarities and difference to Beagle and Tracker and which originates from the unfortunate demise of Kat. The goal of Strigi is quite clear: index user data so that searching for it is fast. The aim is not to index only plain text but also metadata so that a user may search for e.g. 'ext:png width:128' to find all files with a width of 128 pixels Strigi has a few features that are not in Tracker or Beagle and misses a number of features that the other programs lack. But the core functionality of Strigi, indexing data, is something that it shares. One important distinction has to be made straightaway: the difference between indexing metadata and storing metadata. Strigi only indexes metadata. If you think you're disk is full, you can just throw away the index, because there is no data of value in there. All that's in there is an index that allows you to find your data quickly. Personally, I think _storing_ metadata in an indexer is not a good idea. (I do think that an index on a metadata store is a good idea, but that's a different matter). This is a large difference with Tracker which does act as a metadata store of 'first class objects' whatever that means. Beagle is also mainly an index. (Is any non-redundant data lost if I delete my Beagle index, Joe?) So if Tracker and Beagle also index data, what's so special about Strigi? (sorry for the obligatory boasting coming up) - It is KISSest of all - It is fastest of all (for indexing many small files, just parsing is ~100 docs per second, with writing to the index depends on the index backend) - It can index files in files in files in files in files - It has and indexer that can output XML and can this be used by other indexers (Beagle and Tracker) so that indexing code can be shared. Having a common metadata standard would be nice for this purpose, but see below) - It is written in C++ - It has multiple storage backends clearly separated behind an API so that Strigi can always take advantage of the fastest index around (currently clucene) - It can be used for searching even if there is no index, by using the command line programs 'deepfind' and 'deepgrep' [2] This is however not a sales talk. Strigi stands on it's own. It's GUI independent. Currently, it links to clucene or hyperestraier, to libexpat and some other common libs like libz and libcrypto. It has a DBus interface and can be called from any language with DBus support. There's a plugin for GNOME Deskbar in the source code. So it this is not a sales talk, what is it? It's a call for standardization. This discussion between competing programs is a great time to start talking about common functionality. With regards to desktop search there are many things that can be standardized: - query language - metadata names and meaning - test suites - DBus APIs - index formats I won't discuss index formats because, even though Beagle and Strigi both use the Lucene index format, this is an implementation detail and defines performance and disk usage and should not be frozen into a standard. The query language as used by Beagle and Strigi is very similar (no coincidence) and is a good start for standardization. The largest drawback of the language used is the ambiguity of the field specifiers. Now that DBus v1 is almost upon is, the barriers between GNOME and KDE are diminishing. Functionality defined by a DBus API can by implemented in any language and as such, I think GNOME should choose a DBus API to use and share with KDE and Test suites. I'd love there to be a common test suite that says: if you index this data with these parameters, you should get these results from this query. Strigi will develop such test naturally. Being able to share them across projects would mean that programs would compete on merit and without the usual prejudices and license and library incompatibilities. Strigi has a DBus interface for searching, so does Tracker. We should compare them and find a common interface. Of course the respective GNOME and KDE developers should decide which DBus API should be used by their applications. Freedesktop.org would be a good place to define these interfaces.
Re: User Documentation Requirements
On 10/23/06, Shaun McCance [EMAIL PROTECTED] wrote: For those who don't keep archives or have broken threading: http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00232.html Are there any further thoughts about this? I already gave my $0.02 about that. :-) Since I think there is constant confusion about requirements, I'd like to work on the pages here: http://live.gnome.org/ReleasePlanning/ModuleRequirements What I would like to do is put the requirements into five pages: common, new modules, applications, platform, and bindings. I'd like these pages to reflect everything we expect of maintainers. I volunteered to do this a little while ago (http://mail.gnome.org/archives/release-team/2006-August/msg0.html; grep for 'documentation'). Been a little slow at getting back around to it, though I do have some partial drafts laying around. I'll finish them up and get them online, though if you want to beat me to the punch with an initial outline then go ahead. New modules hadn't been included originally, but it looks like Vincent is tackling that (http://mail.gnome.org/archives/release-team/2006-October/msg00044.html) so it shouldn't be hard to incorporate it. And then we should link to this page from, well, just about all the maintainer-oriented pages. http://live.gnome.org/MaintainersCorner (which happens to be linked to from the product overview page in bugzilla and the release schedule) sounds like the most natural place. Might warrant a separate mention on the release schedule as well. And, once it's written up, we should sound out a big announcement to let people know about it. Any other places it belongs? (Or that a link to MaintainersCorner ought to be added?) ___ 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
On Mon, 2006-10-23 at 21:21 +0200, Jos van den Oever wrote: Today I was demo-ing KDE at the Systems in Munich and the GNOME presenter across from me in the GNOME booth told me about this discussion [1] [snip] GNOME are not at Systems. The booth was cancelled. But we have fans everywhere. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
The stand is there, it has a big sticker 'GNOME' and some nice people from Ubuntu took the honeurs thinking that the GNOMEs were absent only for today. Too bad it got cancelled. In fact, the Ubuntu guy did not always did a good job of explaining GNOME. One fair attendee came to the KDE stand saying: so what's this KDE desktop? I came from the GNOME stand and they were a competitor but now redundant due to a license change. That was rather funny. I tried to clarify that neither is redundant and that we're getting closer all the time. Nevertheless, they put a nice demo system up. 2006/10/23, Murray Cumming [EMAIL PROTECTED]: On Mon, 2006-10-23 at 21:21 +0200, Jos van den Oever wrote: Today I was demo-ing KDE at the Systems in Munich and the GNOME presenter across from me in the GNOME booth told me about this discussion [1] [snip] GNOME are not at Systems. The booth was cancelled. But we have fans everywhere. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Notes on the Metacity compositor
The metacity GL compositor was intended to: - move towards the 3D desktop - be a technology demo with a focus on cool effects But given those two gaols, compiz is clearly better than the metacity compositor. So I think that if anybody wanted to pick up the metacity compositor, the focus should probably not be on doing lots of cool effects, but rather on something that would be nice to use. Anyway, here are some technical notes on the metacity compositor, if someone should feel like working on it: How to make it build and work: -- libcm and metacity --enable-compositor should both build and work out of the box. I recently (today) updated libcm to work with the latest texture-from-pixmap API. If you compile CVS head of libcm and metacity, you should get something that works, ie., no blue screens etc. It will be a bit slow, and some of the effects annoying, but it should basically work. Performance Issues: --- Metacity as compositor is slower than compiz on the same hardware. Some potential reasons: - libcm does not use multitexturing to draw windows, compiz does. R100 hardware (such as Radeon 7000) has three texturing units which is a lot for its time, so on that chip (which is the one in T42 ThinkPads), compiz will have a pretty big advantage. - When dragging windows around with metacity, applications are repainting themselves. That doesn't happen with compiz for some reason. For this particular operation this is the main source of slowdown. I don't know why it happens. Architectural issues: - Argb decorations: With composite the X server gained a 32 bit visual intended to be used for ARGB windows. When such an argb window has an rgb child, the X server will do an automatic composite redirection on the child. In a reparenting window manager, the natural way to do decorations with an alpha channel (for antialiased rounded corners maybe) is to just make the decoration window ARGB. Unfortunately, if the application has an RGB window (which is almost always the case), an extra redirection will happen, causing slowdowns and extra memory use. One fix for this would be to make metacity not reparent when it is compositing, another would be to shape the decoration window so that it becomes invisible. - Metacity really needs a wrapper around libX11. There is one in libcm called (Ws) that could be extended as necessary. Things that can be done cleanly that way: - async properties - roundtrip-free error handling - having signals on windows when events arrive - Framework for effects Current metacity has hooks for some events, such as minimization and unminimization. More should be added, but it is not always trivial to get right when windows can be closed and disappear without warning. - Dealing with screens, workspaces and windows I think the model has to be that each of these objects knows how to paint itself. This is different than what we have now, where the compositor is a separate entity that is listeing to what is going on, and then painting what it thinks the world looks like. More generally, I think anybody picking up the metacity compositor should be prepared to change all parts of metacity to become compositor-aware, rather than grafting it on as I did. Soren ___ 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
Jos van den Oever wrote: Hi all, Hi Jos, great to have you in on this discussion. Strigi has a few features that are not in Tracker or Beagle and misses a number of features that the other programs lack. But the core functionality of Strigi, indexing data, is something that it shares. One important distinction has to be made straightaway: the difference between indexing metadata and storing metadata. Strigi only indexes metadata. If you think you're disk is full, you can just throw away the index, because there is no data of value in there. All that's in there is an index that allows you to find your data quickly. Personally, I think _storing_ metadata in an indexer is not a good idea. (I do think that an index on a metadata store is a good idea, but that's a different matter). This is a large difference with Tracker which does act as a metadata store of 'first class objects' whatever that means. Beagle is also mainly an index. (Is any non-redundant data lost if I delete my Beagle index, Joe?) First to clarify, tracker is not a dedicated indexer (like Beagle and Strigi) but is first and foremost a database which has indexing as a side feature. Our metadata store (sqlite) is quite separate from our full text indexer (QDBM) which can be deleted if not required - the data there is just as expendable as in Strigi's and Beagle's case. No metadata is stored in the full text indexer although indexable metadata is of course indexed in it. Tracker can also be run as a stand alone metadata store/server without any indexing if desired (with the --disable-indexing command line option) [snip] So it this is not a sales talk, what is it? It's a call for standardization. This discussion between competing programs is a great time to start talking about common functionality. With regards to desktop search there are many things that can be standardized: - query language - metadata names and meaning - test suites - DBus APIs - index formats I won't discuss index formats because, even though Beagle and Strigi both use the Lucene index format, this is an implementation detail and defines performance and disk usage and should not be frozen into a standard. The query language as used by Beagle and Strigi is very similar (no coincidence) and is a good start for standardization. The largest drawback of the language used is the ambiguity of the field specifiers. Now that DBus v1 is almost upon is, the barriers between GNOME and KDE are diminishing. Functionality defined by a DBus API can by implemented in any language and as such, I think GNOME should choose a DBus API to use and share with KDE and yes this is my desire also. Test suites. I'd love there to be a common test suite that says: if you index this data with these parameters, you should get these results from this query. Strigi will develop such test naturally. Being able to share them across projects would mean that programs would compete on merit and without the usual prejudices and license and library incompatibilities. Strigi has a DBus interface for searching, so does Tracker. We should compare them and find a common interface. Of course the respective GNOME and KDE developers should decide which DBus API should be used by their applications. Freedesktop.org would be a good place to define these interfaces. we should have a org.freedesktop.indexer interface that we can all share. Implementation specific stuff can then reside in their own unique interfaces Metadata naming and meaning. This is something which is rather hard. Dublin Core is part of it. It names some types of metadata. I've already mailed about this with Jamie in the past . In my opionion, the issue should be separated into smaller definitions that say, what metadata fields can be extracted from certain filetypes. Indexer plugins could then advertise that they implement this functionality. The names for the metadata names should also be used when searching and there, for convenience, they should be abbreviated as is current practice. So, rather a long mail that can be summarized in: please accept an API for searching and not a suit of programs (indexer + guis to it) and start thinking about standardizing _indexable_ metadata (other metadata is a whole different can of worms that I wont touch). This is still possible since neither KDE nor GNOME have agreed on a program for indexing and by adopting only an API, programs will be forced to collaborate to adhere to the API as good as possible, meaning the user wins. I agree from the indexing point of view but Gnome requires a reference implementation to be available - in cases where there have been multiple cases, Gnome has always blessed one (EG Epiphany vs Galeon) but that does not mean distros use the blessed one (EG Firefox is more likely to be used as the dominant web browser even though I think Epiphany is better in a Gnome setting) The other
Re: Proposing Tracker for inclusion into GNOME 2.18
On Mon, 2006-10-23 at 21:21 +0200, Jos van den Oever wrote: So it this is not a sales talk, what is it? It's a call for standardization. This discussion between competing programs is a great time to start talking about common functionality. With regards to desktop search there are many things that can be standardized: - query language - metadata names and meaning - test suites - DBus APIs - index formats I would also add extension interface for ISDs. If a developer creates an application that uses its own file formats (or makes use of some other applications' formats), then she should be able to provide an indexer and metadata extractor for those formats. Analogously, ISDs can install thumbnailers for their file formats, and both KDE and Gnome can create thumbnails of those files using the same thumbnailers. This is awesome. I realize that a shared indexer extension system is likely more difficult than a shared thumbnailer extension system. But if short of having only One True Indexer, it's the only way we'll get wide-spread ISD buy-in. -- Shaun ___ 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
Shaun McCance wrote: On Mon, 2006-10-23 at 21:21 +0200, Jos van den Oever wrote: So it this is not a sales talk, what is it? It's a call for standardization. This discussion between competing programs is a great time to start talking about common functionality. With regards to desktop search there are many things that can be standardized: - query language - metadata names and meaning - test suites - DBus APIs - index formats I would also add extension interface for ISDs. If a developer creates an application that uses its own file formats (or makes use of some other applications' formats), then she should be able to provide an indexer and metadata extractor for those formats. Analogously, ISDs can install thumbnailers for their file formats, and both KDE and Gnome can create thumbnails of those files using the same thumbnailers. This is awesome. I realize that a shared indexer extension system is likely more difficult than a shared thumbnailer extension system. But if short of having only One True Indexer, it's the only way we'll get wide-spread ISD buy-in. this is doable via dbus. EG we could have a RegisterMetadataExtractor method that specifies the mime type of the file to be extracted and the path/name of the program that does the extraction. The custom file type would need to make sure it is registered in the shared-mime-info database so that it can be recognised We would then have to agree on the format of the metadata and naming so that it can be imported by all three. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
On Mon, 2006-10-23 at 21:26 +0100, Jamie McCracken wrote: First to clarify, tracker is not a dedicated indexer (like Beagle and Strigi) but is first and foremost a database which has indexing as a side feature. Jamie, can you please explain what exactly Tracker is and does? I have no idea what ‘first class object database’ means, so please explain what you mean by that if you need to. Cheers, -- m ___ 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
Mariano Suárez-Alvarez wrote: On Mon, 2006-10-23 at 21:26 +0100, Jamie McCracken wrote: First to clarify, tracker is not a dedicated indexer (like Beagle and Strigi) but is first and foremost a database which has indexing as a side feature. Jamie, can you please explain what exactly Tracker is and does? I have no idea what ‘first class object database’ means, so please explain what you mean by that if you need to. http://live.gnome.org/ResearchAndDevelopment/Tracker -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
[ cross-post reduced d-d-l ] Jamie McCracken wrote: Some people might not like that but I think its a practical compromise. With tracker being the only one written in pure C it is therefore the only one that can *ultimately* get into the Gnome platform and be fully integrated (at the moment I am just proposing it for desktop which is just a simple blessing nothing more). What is the problem with having C++ into the platform? After all C++ does not bring more dependencies, and C++ does not implies C++ APIs. Is there any written policy or is that just personnal anti-C++ FUDing like it is pretty common in the Gnome world with mostly misinformed statement about performance, etc ? Hub ___ 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
Mariano Suárez-Alvarez wrote: I have no idea what ‘first class object database’ means, so please explain what you mean by that if you need to. http://en.wikipedia.org/wiki/First_class_%28computing%29 ___ 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
Hubert Figuiere wrote: [ cross-post reduced d-d-l ] Jamie McCracken wrote: Some people might not like that but I think its a practical compromise. With tracker being the only one written in pure C it is therefore the only one that can *ultimately* get into the Gnome platform and be fully integrated (at the moment I am just proposing it for desktop which is just a simple blessing nothing more). What is the problem with having C++ into the platform? After all C++ does not bring more dependencies, and C++ does not implies C++ APIs. Is there any written policy or is that just personnal anti-C++ FUDing like it is pretty common in the Gnome world with mostly misinformed statement about performance, etc ? AFAIK GNOME platform is currently C only. FWIW, I have nothing against C++ or any other *native* (IE non-VM) language being included there. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
quote who=Jamie McCracken Jamie, can you please explain what exactly Tracker is and does? I have no idea what ‘first class object database’ means, so please explain what you mean by that if you need to. http://live.gnome.org/ResearchAndDevelopment/Tracker Jamie, You're proposing the addition of an entirely new technology to GNOME, with the intention that at some stage it could enter the Platform and be used by many (if not almost all) applications. You need to be clear, succinct, and explain *what* it is, what it *does* and *why* it is important. Think elevator pitch and use cases, rather than essay and hypotheticals. During this discussion, you've pitched Tracker as an indexer competitive with Beagle, then as a first class object database possibly in line with the old Storage ideas, then suggested that the indexer was secondary to the first class object database. This doesn't really raise confidence in your ability to define the problem space, let alone solve the problem. Great technology loses out to poor communication (be it directly social or marketing) all the time. If you want to ensure your technology doesn't fall into a coma of irrelevance, you *need* to step up and communicate it well. Thanks, - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Ah, now we see the violence inherent in the system. - From Monty Python to ESR, by way of Al Viro ___ 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
Analogously, ISDs can install thumbnailers for their file formats, and both KDE and Gnome can create thumbnails of those files using the same thumbnailers. This is awesome. Back to a technical question... This reminds me, does Tracker use the freedesktop thumbnail spec like nautilus does? If a file does not have a thumbnail, does tracker try to create one itself, or does it ask the gnome ThumbnailFactory to do so? John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
On Mon, 2006-10-23 at 17:54 -0400, Havoc Pennington wrote: Owen was showing me FC6 this morning, and it does seem to work out nicely having metacity handle the old video hardware and compiz handle the new, with a simple toggle between them. The only real glitch in it was that compiz uses EWMH-viewports to implement workspaces, which I think is probably a bad choice; the exact same user-visible behavior could be done with the EWMH-workspace implementation If compiz used workspaces instead of viewports, you wouldn't be able to have a window wrapped around an edge of the cube and thus partially visible on two different sides. No, I'm not claiming that's a *good* reason. :-) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
On Mon, 2006-10-23 at 18:19 -0400, Dan Winship wrote: On Mon, 2006-10-23 at 17:54 -0400, Havoc Pennington wrote: Owen was showing me FC6 this morning, and it does seem to work out nicely having metacity handle the old video hardware and compiz handle the new, with a simple toggle between them. The only real glitch in it was that compiz uses EWMH-viewports to implement workspaces, which I think is probably a bad choice; the exact same user-visible behavior could be done with the EWMH-workspace implementation If compiz used workspaces instead of viewports, you wouldn't be able to have a window wrapped around an edge of the cube and thus partially visible on two different sides. No, I'm not claiming that's a *good* reason. :-) That's a great reason! ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
Dan Winship wrote: On Mon, 2006-10-23 at 17:54 -0400, Havoc Pennington wrote: Owen was showing me FC6 this morning, and it does seem to work out nicely having metacity handle the old video hardware and compiz handle the new, with a simple toggle between them. The only real glitch in it was that compiz uses EWMH-viewports to implement workspaces, which I think is probably a bad choice; the exact same user-visible behavior could be done with the EWMH-workspace implementation If compiz used workspaces instead of viewports, you wouldn't be able to have a window wrapped around an edge of the cube and thus partially visible on two different sides. Just not true, afaik - that's what I mean by the exact same user-visible behavior could be done with the EWMH-workspace implementation. I'm sure it's annoying to change at this point, of course, but it's also kind of annoying to go fix up apps and libwnck and gtk and so forth to deal with either implementation approach. The good news is that not many apps care, probably. Havoc ___ 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
quote who=Jamie McCracken As this stage I am simply proposing tracker-search-tool as a replacement for the gnome-search-tool as I believe it does a better job with faster instant search and search snippets. That was not entirely clear from previous emails in this thread. In that case, please explain *what* t-s-t is, what t-s-t *does* and *why* t-s-t is so important that we should replace working code with it. Those are the things people need to know, not that you believe it does a better, faster, fitter, healthier, more productive job. It would be fantastic for Gnome 2.18 to have this around the time Vista ships and with a common dbus interface for indexing, Beagle too can benefit by effectively being in too for those that want more indexing than tracker currently provides (I dont plan on indexing as much as Beagle or maybe Strigi so there is bound to be room for them too). So, if Tracker doesn't do indexing as a priority, and doesn't cover similar ground to Beagle, why are you positioning it as a choice? Why don't we just use Beagle, which has already shipped with various distributions? - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Love never misses the chance to put the boot in. - Kelly, SLOU ___ 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
Jeff Waugh wrote: quote who=Jamie McCracken As this stage I am simply proposing tracker-search-tool as a replacement for the gnome-search-tool as I believe it does a better job with faster instant search and search snippets. That was not entirely clear from previous emails in this thread. In that case, please explain *what* t-s-t is, what t-s-t *does* and *why* t-s-t is so important that we should replace working code with it. Those are the things people need to know, not that you believe it does a better, faster, fitter, healthier, more productive job. If you read the first email it did state that. t-s-t uses the same code as g-s-t so it inherits the working code. Its a better search tool because it can show search snippets like google as well as providing high speed search. It would be fantastic for Gnome 2.18 to have this around the time Vista ships and with a common dbus interface for indexing, Beagle too can benefit by effectively being in too for those that want more indexing than tracker currently provides (I dont plan on indexing as much as Beagle or maybe Strigi so there is bound to be room for them too). So, if Tracker doesn't do indexing as a priority, and doesn't cover similar ground to Beagle, why are you positioning it as a choice? Why don't we just use Beagle, which has already shipped with various distributions? Indexing is part of Tracker - its just not the only *part*. Its not a matter of priority as such. We will be indexing all the important stuff (files, applications, emails and conversations) As for Beagle, you'll have to ask the Beagle devs why beagle is not ready I for one cant run beagle well on my 256MB machine until they sort out the memory issues so its kinda of a non-starter. Tracker should be able to run well on any machine that can run GNOME and thats why it should be the default and in the Gnome desktop. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
snip Indexing is part of Tracker - its just not the only *part*. Its not a matter of priority as such. We will be indexing all the important stuff (files, applications, emails and conversations) Lets talk specifics here. Can you create a page like [1] for Tracker? http://beagle-project.org/Supported_Filetypes Corey ___ 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
quote who=Jamie McCracken t-s-t uses the same code as g-s-t so it inherits the working code. Its a better search tool because it can show search snippets like google as well as providing high speed search. And it does so by using... Tracker? Which means you're not just proposing t-s-t, but the Tracker indexer and database? You really need to start being clear now. As for Beagle, you'll have to ask the Beagle devs why beagle is not ready We have a pretty clear email from Joe about that, and what he needs to do to rectify the situation. We're not getting much clarity from you, and if you want us to understand your intentions, you need to fix this. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ ... Of course, compared with Holly Valance, who has beams of light shooting from her nipples, it all seems rather quaint now. - Rove McManus on Olivia Newton-John ___ 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
Jeff Waugh wrote: quote who=Jamie McCracken t-s-t uses the same code as g-s-t so it inherits the working code. Its a better search tool because it can show search snippets like google as well as providing high speed search. And it does so by using... Tracker? Which means you're not just proposing t-s-t, but the Tracker indexer and database? You really need to start being clear now. yes we are proposing the lot - sorry for any confusion there As for Beagle, you'll have to ask the Beagle devs why beagle is not ready We have a pretty clear email from Joe about that, and what he needs to do to rectify the situation. We're not getting much clarity from you, and if you want us to understand your intentions, you need to fix this. sorry, is anything else still unclear? -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
On Mon, 23 Oct 2006, Jamie McCracken wrote: Hubert Figuiere wrote: [ cross-post reduced d-d-l ] Jamie McCracken wrote: Some people might not like that but I think its a practical compromise. With tracker being the only one written in pure C it is therefore the only one that can *ultimately* get into the Gnome platform and be fully integrated (at the moment I am just proposing it for desktop which is just a simple blessing nothing more). What are the chances of a version of Beagle ever using the C Lucene backend, which as Jos has mentioned is currently faster? Has the C# Lucene diverged too far away from C Lucene? I have long wondered why C# Lucene was developed in the full knowledge that C Lucene would be preferable to Gnome and now finally seems like an appropriate time to ask. -- Alan ___ 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
Jamie McCracken wrote: I know this is a bit late in the hour but I should be in the nick of time as the new modules proposals deadlines ends in a few hours! So well, what modules are you proposing ? the Tracker database and indexer ? Use cases that looks interesting to me wrt tracker and that I'd like to see developped: - using it as a backend for gedit to store its own metadata about files (like current line number, syntax highlighting used, etc.) - common database for pictures (f-spot) or music (rhythmbox, banshee), possibly faster than the current backends for those. I'm not really interested in the indexer aspect of tracker (I don't use 'search' often and I don't see any other use case) A side question: is it possible for tracker to track in some way the backuped files ? I'm thinking about burned CDs containing pictures, since f-spot for instance is not capable of telling me the pics you are looking for were burned on the BLAH_2006 photo CD! ___ 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
quote who=Jamie McCracken sorry, is anything else still unclear? Go back to my mail, read it again, and start from the beginning. What is it, what does it do, why is it important? Tell us a story with an elevator pitch and use cases, not an essay with hypotheticals. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I tried to make money ass signing, but the bottom fell out of the market. - Liam Quin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
On Mon, 2006-10-23 at 18:32 -0400, Havoc Pennington wrote: Dan Winship wrote: If compiz used workspaces instead of viewports, you wouldn't be able to have a window wrapped around an edge of the cube and thus partially visible on two different sides. Just not true, afaik - that's what I mean by the exact same user-visible behavior could be done with the EWMH-workspace implementation. Compiz could still display the window on both cube faces, but the EWMH doesn't provide any way of explaining that state to anyone else, so other EWMH-based tools like the pager would see the window as being on only one face at a time (and would show it as being truncated at the edge of that face). (Admittedly, this problem exists in the viewport model too, but only on the edge where the left and right sides of the virtual desktop meet, rather than at every edge.) I'm sure it's annoying to change at this point, of course It's not actually; if you're not going to change compiz's visible behavior, then you don't need to change its internal representation either, so the only code that needs to change is to make it set/listen to the workspace-related EWMH hints rather than the viewport ones. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
Any chance you could do a release first, so non-{SUSE,CVS} users can try
it out? :)
Sure. You can find a tarball of v0.6.3 at
http://jimmyk.org/gnome-main-menu/.
Thanks!
jimmyk
___
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
Jeff Waugh wrote: quote who=Jamie McCracken sorry, is anything else still unclear? Go back to my mail, read it again, and start from the beginning. What is it, what does it do, why is it important? Tell us a story with an elevator pitch and use cases, not an essay with hypotheticals. - Jeff (okay here goes - now that I have looked up what an elevator pitch is! I will try to be brief...) What is it? Tracker is a personal search tool and storage system that allows you to search and enhance your personal data with the minimum of fuss. It allows you to find the proverbial needle in your computer's haystack as well as providing a one stop solution to the organisation, storage and categorisation of your data. What does it do? Tracker trawls through your data and organises it so that it can be retrieved extremely quickly later on via simple searches. This organisation puts your data into categories so that application like photo managers and music players can instantly find relevant content automatically Tracker enables you to tag your data with keywords which can be used to find related information or to group and categorise your data further Tracker lets you extend your data with additional metadata Why is it important? Tracker provides a framework for desktop search which nearly all modern platforms provide Tracker provides fast search and fast indexing whilst using considerably less memory than its competitors such that it can be used on almost any reasonable machine. Tracker provides common storage for important data which enhances the performance and integration of your desktop Tracker makes it easy to access the files you want without navigating through painful hierarchies as is all too common these days. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
quote who=Jamie McCracken (okay here goes - now that I have looked up what an elevator pitch is! I will try to be brief...) This is a pretty airy-fairy description for a developer mailing list. Your audience is not my Mum, it's the group of people architecting GNOME. You did not include use cases in your description. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ A computer with a bullet in it is just a paperweight, A map with a bullet in it is still a map. - Maj. Keith Hauk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
When i checked it out of the cvs a couple of months back, i noticed a few things. - docpath to search for docs is bad, this in an extension on the .desktop file. - the default gnome preferences menu is settings.menu not preferences.menu, if it stays this way not everything will show up. Thanks for the patches for these, I'll work on integrating them. - also for some reason it showed a package manager which seems to be integrated with the desktop file and/or rpm. Wrote a patch so if the gconf key was empty it wouldn't show. This has been fixed since in the last month or so. So I'd rather see you make a release, get an entry on the bug tracker and try to comply to the gnome standard way instead of the suse way. I've made a release at http://jimmyk.org/gnome-main-menu/. I'm not yet sure how to get it into the bug tracker, but surely it can't be that big of a deal. Are there things which do not comply with the gnome standard way besides what you've already mentioned in this mail? If so, could you elaborate a bit? Thanks! jimmyk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
Dan Winship wrote: Compiz could still display the window on both cube faces, but the EWMH doesn't provide any way of explaining that state to anyone else, so other EWMH-based tools like the pager would see the window as being on only one face at a time (and would show it as being truncated at the edge of that face). (Admittedly, this problem exists in the viewport model too, but only on the edge where the left and right sides of the virtual desktop meet, rather than at every edge.) There's already a workspace geometry provided to the pager, so I bet all you'd need to convey to it is a single bool for whether windows overlap in this way, and then when drawing the mini-windows on the mini-workspaces change the clip region so it always includes all the mini-workspaces instead of just one. Or something like that. Even if this isn't fixed, it seems a like a not-very-bad bug. It's not clear to me what I'd expect when a cube is mapped onto a 2D grid anyway ;-) I don't know exactly how it would all play out, I just think it makes life simpler if everyone pretends EWMH didn't have the second gratuitous way to implement the same thing (workspaces). The only reason it exists AFAIK is that some WM authors wanted to implement workspaces-inside-workspaces, which I consider nuts. I could flip a coin for whether windows should overlap workspaces (no strong view), but I do have a strong bias against having two slightly-different-but-almost-the-same concepts of workspace, one nested inside the other... Assuming that bias, there's no real point having two ways to implement the one concept of workspace, instead you just want a flag for whether windows overlap... GNOME right now basically just pretends EWMH doesn't have the viewport thing. Anyway, not trying to push you around just offer historical context ;-) Havoc ___ 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
On 10/24/06, Jeff Waugh [EMAIL PROTECTED] wrote: quote who=Jamie McCracken sorry, is anything else still unclear? Go back to my mail, read it again, and start from the beginning. What is it, what does it do, why is it important? Tell us a story with an elevator pitch and use cases, not an essay with hypotheticals. OK I am not the developer, but from the perspective of a user of tracker, here is an elevator pitch; Tracker helps you find and organize your stuff. Imagine downloading a mp3 file to have it automatically have it appear in Rhythmbox, complete with artist and track information. Imagine shooting a photo on your digital camera, and to have it appear in f-spot, without having to be imported. Like tagging? tracker lets you apply tags to files, freeing you from an endless heirarchy of folders. Tracker not only allows you to search for files based upon whats inside them, but also by properties which describe them (metadata). Tracker is smart, by treating files as first class objects it knows that Photos have widths, while Music files have artists. Tracker knows that documents have authors and Videos have durations. Want to find photos taken with you Nikon digital camera? no problem!. Want to find all Openoffice documents created in december, with more than 10 pages, containing the word cheese? no problem. Tracker can do it. Tracker is; * Small - 5mb ram, great for low end systems. * Fast - 100s of searches per second will not slow your computer, drain your battery or eat your cat. * Standards compliant - want to write a gnome app in bash? no problem, tracker has a dbus interface Tracker is the glue that helps developers connect GNOME together, and the reason users will love the GNOME platform. John - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I tried to make money ass signing, but the bottom fell out of the market. - Liam Quin ___ 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: Proposing Tracker for inclusion into GNOME 2.18
Jeff Waugh wrote: quote who=Jamie McCracken (okay here goes - now that I have looked up what an elevator pitch is! I will try to be brief...) This is a pretty airy-fairy description for a developer mailing list. Your audience is not my Mum, it's the group of people architecting GNOME. You did not include use cases in your description. Use Cases: 1) Full desktop search system 2) Extensible metadata server including tags (metadata throughout the system) 3) Can be used as the basis for the implementation of the Topaz style object model as defined in : http://live.gnome.org/ThreePointZero/Model 4) Common database for music and photos so that these applications can store all their data here which is shareable and searchable by other apps -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
quote who=Jamie McCracken This is a pretty airy-fairy description for a developer mailing list. Your audience is not my Mum, it's the group of people architecting GNOME. You did not include use cases in your description. Use Cases: Jamie, these are not use cases. Unfortunately, you've got this entirely backwards: Your pitch should be to developers; your use cases should be about what users need (often unspoken), and how Tracker satisfies those needs - these use cases may be from end users or developer users... But to be effective, they must be described as *use cases*. I'm asking for a very specific form of description because thus far, there isn't a lot of knowledge or mindshare of Tracker, and your descriptions have not made it easy for developers to understand your point of view, or what Tracker brings to GNOME. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I don't know whose brain child it was, but it was quite an ugly child. ___ 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
Jeff Waugh wrote: quote who=Jamie McCracken This is a pretty airy-fairy description for a developer mailing list. Your audience is not my Mum, it's the group of people architecting GNOME. You did not include use cases in your description. Use Cases: Jamie, these are not use cases. Unfortunately, you've got this entirely backwards: Your pitch should be to developers; your use cases should be about what users need (often unspoken), and how Tracker satisfies those needs - these use cases may be from end users or developer users... But to be effective, they must be described as *use cases*. I'm asking for a very specific form of description because thus far, there isn't a lot of knowledge or mindshare of Tracker, and your descriptions have not made it easy for developers to understand your point of view, or what Tracker brings to GNOME. okay thanks for the clarification I will come up with something tomorrow that hopefully addresses these. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
On Mon, 2006-10-23 at 23:21 +0100, Jamie McCracken wrote: The main reason was I didn't like the way GNOME uses loads of different, inefficient and incompatible means of storing information (think Berkeley DB for EDS, MBox for emails, the zillions of small performance draining XML files used for bookmarks, history, rhythmbox's music database and many other things). So, I wanted to bring together all this stuff under one centralised database and in doing so increase performance, power and memory efficiency of the platform as a whole. Be very careful with trying to put disparate kinds of data under the same storage. Read these articles: http://www.joelonsoftware.com/articles/fog18.html http://www.jwz.org/doc/mailsum.html And then consider whether you indeed want to put everything under the same database. Global indexers: good. We need that. Global metadata: good. Does anyone but me miss the reliable, fast, and simple metadata storage that we used in GNOME 1.2? A database to put everything because databases can store EVERYTHING: bad. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
On 23 Oct 2006 22:17:32 +0200, Soeren Sandmann [EMAIL PROTECTED] wrote: - Framework for effects Current metacity has hooks for some events, such as minimization and unminimization. More should be added, but it is not always trivial to get right when windows can be closed and disappear without warning. I don't think the hooks are enough. For example, when you minimize a window, Metacity draws an animation consisting of black rectangles after the window has been unmapped. I once tried to change it so that it would look more like the minimize animation in MS Windows. One of the big differences is that in Windows, the animation is drawn before the window is unmapped. So Metacity had to be changed so that the animation was drawn before the window is unmapped. It was nontrivial. And I think it would be even harder to adapt the hooks so that it could support animations both before and after the window is unmapped. That is just one example, but it seems to me that Metacity wasn't designed with flashy graphical effects in mind. One has to wonder: Is the effort required to make Metacity's compositing as good as Compiz greater or smaller than making Compiz as usable and mature as Metacity? Has anyone analyzed Compiz code and compared? -- mvh Björn ___ 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
On Mon, 2006-10-23 at 22:15 +0100, Nick Murtagh wrote: Mariano Suárez-Alvarez wrote: I have no idea what ‘first class object database’ means, so please explain what you mean by that if you need to. http://en.wikipedia.org/wiki/First_class_%28computing%29 That's database jargon, and it's completely uninteresting to users. Think of first-class with the same usage in which you would say the Scheme language provides first-class functions and environments. Just like you can create integers, pass them to functions, and return them from functions, in Scheme you can also create functions, pass them to other functions, and return them from functions. Same thing with environments [what they are in Scheme's terms is not interesting for this discussion]. The idea is that an object is first-class if you can create it, manipulate it, and embed it just like any of the most fundamental objects in your language. In GNOME we've been throwing the term first-class objects since GUADEC 2004 in Kristiansand. The idea is that users have different kinds of data, roughly grouped as documents, contacts, mails, appointments, bundles, etc., but it is very difficult to combine data of different types, or associate that data together. For example, it's hard to send a contact to someone without explicit support in the applications. You may have some luck in dragging a contact out of your addressbook into your mail program; ideally, the mail should get a vCard attachment. On the recipient's side, you can often add a vCard attachment to your addressbook reasonably easily. However, mail and contacts are so closely related that the programs that handle them often have explicit hooks for each other's data. It's very rare that you can do things like the following. You get a vCard attachment. You want to drag that contact and drop it to your desktop: I'll put this contact here so that I'll remember to call him later. How would this work? Do you want the file manager to see that it is being dragged something of type text/vcard (or whatever the right MIME type is), and then run some ad-hoc code to render a contact on your desktop? Or should it call out to the addressbook to render the contact? Or should it just display a generic vCard icon, and hope that you have the right MIME-to-program associations for when you double-click the icon later? I have this stone-age PDA that lets you create notes (a General Magic DataRover). Then it lets you create little drawings. Then you can drag your drawings into the notes, just like that, and place them anywhere. You can also drag contacts into the notes. You can link the notes into your calendar appointments. The Right Thing(tm) just happens when you manipulate these objects into others. It's hard to define just what happens in every case, but when you see it happen, it feels very comfortable and natural. The idea behind first-class objects is that you get that kind of flexibility. I have no idea what the APIs for that PDA looked like. I don't know if the notes/drawing/contacts/calendar programs in it were hardcoded to accept each other's data seamlessly, or if their APIs were flexible and pluggable enough that you could do this with any kind of data. Defining first-class objects is very hard in GNOME's context, because we are not sure what kinds of objects we want to have, nor what kinds of actions we want to be able to perform among them. It would be very productive to do some archaeology for the DataRover's APIs and history. Take a look at OpenCroquet as well. It is mightily pluggable and flexible, and data of different types just seems to flow smoothly from program to program. I'm sure we could use some interesting ideas from there. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Old systems research, worthy starting points [Re: Proposing Tracker]
quote who=Federico Mena Quintero Defining first-class objects is very hard in GNOME's context, because we are not sure what kinds of objects we want to have, nor what kinds of actions we want to be able to perform among them. It would be very productive to do some archaeology for the DataRover's APIs and history. Palm OS research would be worthwhile for similar reasons. Both are old, but *fascinating*. [Yeah, maddog gave me a Data Rover too. ;-)] A great place to start, in terms of worthwhile 'objects' and 'actions' to consider comes from the mantra: People, Events, Documents, Conversations, Getting Laid. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I'm offering you my body, and you're offering me semantics. - Caitlin, Clerks ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
On Mon, 2006-10-23 at 20:27 -0400, Havoc Pennington wrote: Assuming that bias, there's no real point having two ways to implement the one concept of workspace, instead you just want a flag for whether windows overlap... Yawn. http://mail.gnome.org/archives/desktop-devel-list/2002-April/msg00643.html Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on the Metacity compositor
BJörn Lindqvist wrote: That is just one example, but it seems to me that Metacity wasn't designed with flashy graphical effects in mind. One has to wonder: Is the effort required to make Metacity's compositing as good as Compiz greater or smaller than making Compiz as usable and mature as Metacity? Has anyone analyzed Compiz code and compared? .02, If the goal is no regressions to any metacity details (especially handling of bizarre in-house apps using motif/tk/plain-Xlib-and-GL/whatever, but also stuff like arcane ICCCM details, UI behavior details, a11y, and whatever), then starting from metacity is going to be easier. Joel's article applies, http://www.joelonsoftware.com/articles/fog69.html *However* - no regressions is a dumb goal for most GNOME audiences. In fact, metacity became popular well before it had fixed all that gunge I just mentioned. Because most people never encounter or care about all that. (One reason it's hard to get it all fixed - the people who care about it are late adopters.) In the end a good enough window manager just isn't that complicated. I was using Metacity for myself maybe a week or two into writing it. Looking at the ChangeLog, the first stable release was after 1 year, and while I may remember wrongly, I don't think I was working on it full-time. Of course, there are hundreds of fixes after that, but it was good enough after a year. A WM is not rocket science which is why there are so many of them. So, if the goal is to get the new graphics capabilities, and be 90-95% OK on the details, then Compiz is unquestionably the faster route given that it's already there and people are working on it. And nobody is working on metacity compositing. If Compiz _didn't_ exist then I wouldn't advocate starting from scratch. Some of the tricky bits from metacity could have been kept in a way that would avoid regressions, and I don't really agree with suggestions that the code could not be refactored. However, it would not have been as fun as starting over, or offered a sense of ownership/autonomy, so a volunteer developer probably wouldn't ever do this. It kind of comes down to target audience again. The thin client and lots-of-old-UNIX-apps-in-the-enterprise kind of customers aren't going to see any value in Compiz, just pain from random regressions. However, the Fedora/Ubuntu-using GNOME audience, which is probably larger, I'd expect to switch to Compiz pretty quickly, at least those of them who have an acceptable video card. The FC6 solution (allow people to toggle metacity/compiz) seems like a good way to serve those two audiences, though the more compiz and metacity share the same interface to apps and the rest of the desktop (gconf keys, EWMH implementation, themes, default configuration/keybindings, etc.) the better it will work since documentation, apps, control panels, etc. won't have to be different across the two. The hosed audience I'm guessing will be anyone who really needs just one or two simple compositing features (maybe a magnifier for a11y), but also needs to use some crufty old apps or a thin client setup or old video card or other weird cases that metacity already works with. The FC6 solution is no good for someone with that requirement set. Maybe there's some value in making metacity a simple 2D compositor for this audience, I don't know. The caveats for me personally about Compiz are 1) how much time people have spent on metacity, not by me in recent memory, but by quality contributors like Elijah; certainly not wasted time since metacity has been used by many people for many years, and will take a while to vanish yet, but it's always nice to see code live longer rather than shorter, and it would have been nice to keep some more of that work. 2) I don't think WM changes will bring GNOME to new audiences, it's a preaching to the converted kind of feature. With Vista and OS X, perhaps Compiz is like metacity was 5 years ago, in that it brings Linux up to a minimum standard of basic parity and sanity with the competition. But I don't think it creates an edge or killer app. So if I had a wish it's that Compiz gets nailed down and done as quickly as possible, and people move on to things that will create an edge for _new_ audiences. In the end Compiz is nice work and people like it and GNOME should take advantage. And I can't tell you how much I'm looking forward to filing some completely unreasonable window manager bug and then raising hell when the maintainer rejects my demands ;-) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
