Re: Proposed external dependency: libnotify
Hi, On Wed, 2007-08-01 at 04:12 +, BJörn Lindqvist wrote: It is the daemon that drives the speech bubbles that are shown in the notification area on the gnome-panel. Christian explains: notification-daemon *requires* libsexy. It can't be made an optional dependency, as SexyUrlLabel, part of libsexy, is the only way of providing a block of text without decorations that can contain inline hyperlinks. http://mail.gnome.org/archives/release-team/2006-February/msg00062.html It looks like thos: http://www.chipx86.com/w/images/b/b5/Sexy-url-label-1.png Then why not just copy this widget to the notification-daemon source tree? It's probably just two files and the problem would be settled. At some point this funtionality will be integrated into GTK+ and this little hack can be removed then. Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libnotify
Hi everyone. Deja vu. I guess I'll give the usual response to this thread :) I had a blog entry a while back addressing exactly why I didn't want projects to do this. libsexy is not libegg and I'm not wild about having to maintain two copies of the widget. libsexy is at this point bundled on nearly every distribution shipping GNOME, to my knowledge. These distros are shipping notification-daemon and libnotify as well. It's pretty much a de facto standard at this point. libsexy itself is used by a variety of GNOME applications now including Rhythmbox, gedit and xchat-gnome. I would love to get libsexy's widgets bundled into GTK+, but that will require some extensions to widgets such as GtkEntry and GtkLabel to allow subclasses to better hook into the PangoLayouts of the widgets (by providing a signal indicating that the layout has been created and can now be modified). This would get rid of some of the hacks we have to use in libsexy, which would increase the chances of getting into GTK+. Any help would be appreciated here. In the meantime, I'll ask the same question as I did before. Can we just consider libsexy or notification-daemon a blessed dependency given how widespread they both are these days? Or just allow libsexy and use that as motivation to getting GTK+ in shape to be able to include its widgets? Christian On 7/31/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2007-08-01 at 04:12 +, BJörn Lindqvist wrote: It is the daemon that drives the speech bubbles that are shown in the notification area on the gnome-panel. Christian explains: notification-daemon *requires* libsexy. It can't be made an optional dependency, as SexyUrlLabel, part of libsexy, is the only way of providing a block of text without decorations that can contain inline hyperlinks. http://mail.gnome.org/archives/release-team/2006-February/msg00062.html It looks like thos: http://www.chipx86.com/w/images/b/b5/Sexy-url-label-1.png Then why not just copy this widget to the notification-daemon source tree? It's probably just two files and the problem would be settled. At some point this funtionality will be integrated into GTK+ and this little hack can be removed then. Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libnotify
On Wed, Aug 01, 2007 at 12:51:22AM -0700, Christian Hammond wrote: I would love to get libsexy's widgets bundled into GTK+, but that will require some extensions to widgets such as GtkEntry and GtkLabel to allow subclasses to better hook into the PangoLayouts of the widgets (by providing a signal indicating that the layout has been created and can now be modified). This would get rid of some of the hacks we have to use in libsexy, which would increase the chances of getting into GTK+. Any help would be appreciated here. widespread they both are these days? Or just allow libsexy and use that as motivation to getting GTK+ in shape to be able to include its widgets? An item called libsexy cherrypicking has been on the list of features for GTK+ 2.12, but unfortunately didn't make it. If anybody wants to pick up the ball on this, and create a patch against GTK+ that adds the most useful libsexy features (I am thinking of things like adding an icon inside GtkEntry, etc) to GTK+, that would be great. regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On 31/07/07, Havoc Pennington [EMAIL PROTECTED] wrote: This server is a test instance so we can eat our own dogfood, and any data on it may be nuked, accidentally leaked due to bugs in the code, etc. Generally we deploy to dogfood straight from SVN latest with no testing. Please adjust your expectations and behavior accordingly. Reporting bugs is good though, that's the point even. Is there a way to get an account on a test instance such as this one, for hacking on the Mugshot server? It's a nontrivial thing for me to get access to a Fedora box where I have permissions to install all the custom Java and things (or can persuade the admin to); I think I might have one in mind, but it'll be a while yet. It would be good if there was a way to test things without this barrier to entry. Of course, maybe I should just figure out how to install all the tools on Ubuntu (since there are at least two Ubuntu boxes I can test with at present) and document that-- but I thought I'd ask. peace Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On Tue, 2007-07-31 at 16:38 -0700, Sanford Armstrong wrote: GNOME is going to have to become a service provider. as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. The online desktop for personal data storage makes a lot of sense (personal images, videos, calendars, adressbooks, etc), but it makes also a lot of sense for *shared* data storage. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On Tue, 2007-07-31 at 17:48 -0400, Havoc Pennington wrote: Hi, The bleeding edge server code is now up at: http://dogfood-online.gnome.org:9080/ And the old skin: http://dogfood.mugshot.org:9080/ I can't create an account on neither of them. The first one's 'Send' button for obtaining a sign up link does nothing, and the second one just told me I'll be contacted once there's room for me :-( -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
2007/8/1, Rodrigo Moya [EMAIL PROTECTED]: On Tue, 2007-07-31 at 16:38 -0700, Sanford Armstrong wrote: GNOME is going to have to become a service provider. as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. I was about to send a mail about it too. :-) Basically, a new art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. I would love to add support to the control center for this feeds, however, I would like to consolidate the services to do so and think of a good ui for it. The second step is in progress already, but with the first one I'm quite lost, merging several theming sources (gnome-look, art.gnome.org) into one as a mashup and single point would be the ideal solution for this, so users don't need to handle those feeds within applications. [0] http://aruiz.typepad.com/siliconisland/2007/07/jilorio-gnome-b.html -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. Maybe we should also consider a web page to access your notes, which would let you get to them from a random internet kiosk and the like. For a small quota we can support quite a few users without too much trouble. Think a reasonable hard drive (200G) divided by a 10M quota. For a larger quota, one way we could approach it is that the server offers you a choice of storage providers. In implementation, this could mean that if I want to be a storage provider I either set up an S3 account or I provide the similar http-like S3 API on my own server - maybe just support sftp. Then users on online.gnome.org (or another instance of the same code) choose the storage provider they want to use. The server code already has the basic glue to speak WebDAV and forward it to S3, though it isn't enabled through any usable UI. This is only one possibility, though. We might have better ideas later. Something to consider, on the server we can store files or we can store database tables. They both have some advantages, with the database tables we can do fine-grained change notification over XMPP and it's easier to support a web view and web editing. With files it's easier to deal with large (exact definition fuzzy) data. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Thomas Thurman wrote: Is there a way to get an account on a test instance such as this one, for hacking on the Mugshot server? Not yet. The main practical problem right now is that the test instance is on the same machine as the real instance, which means if we gave you an account you could access real data not just test data. Of course, maybe I should just figure out how to install all the tools on Ubuntu (since there are at least two Ubuntu boxes I can test with at present) and document that-- but I thought I'd ask. Definitely this is needed and it should be pretty darn easy, I would say the only thing you have to do is repackage that JBoss RPM we have as a .deb. It doesn't have any system dependencies to speak of, it's all platform-independent Java code, so there should be essentially no work involved in doing this. Or even, you could just install the rpm with alien or rpm2cpio and I'm sure it would work fine. The jboss RPM is just a bunch of files afaik. Other than that the main requirements are simple and probably already available. The Sun JDK (for now - we expect the recently released 100% open source Java to work in the near future), and some common Java libs like ant and junit. If you start going through it, just bug someone on IRC as soon as you hit the slightest problem since we can probably tell you the answer much faster than if you spend time trying to figure it out. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Rodrigo Moya wrote: as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. That would be fantastic I think. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Alberto Ruiz wrote: Basically, a new art.gnome.org http://art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. In addition to themes, I think it would be sweet if you could choose backgrounds from art.gnome.org and also photo sharing sites like Flickr in the control panel. And to make it more badass, have the control panel remember the original URL of the image, which combined with settings sync means if you log in to a fresh account your background would be downloaded ;-) Then of course there's the slideshow background from my photoset/tag feature... Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Rodrigo Moya wrote: I can't create an account on neither of them. The first one's 'Send' button for obtaining a sign up link does nothing, and the second one just told me I'll be contacted once there's room for me :-( I forgot to include one of the javascript files, and then Owen started swapping out the XMPP server for a newer upstream version and so the latest svn was too busted to just push the quick fix. We'll get it fixed today. Bleeding edge svn snapshot, woot! Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
2007/8/1, Havoc Pennington [EMAIL PROTECTED]: Hi, Alberto Ruiz wrote: Basically, a new art.gnome.org http://art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. In addition to themes, I think it would be sweet if you could choose backgrounds from art.gnome.org and also photo sharing sites like Flickr in the control panel. Errr... have you seen the link at the bottom of my previous e-mail? Anyway, direct link to the screencast: http://youtube.com/watch?v=reB9TNRQ1Bg And to make it more badass, have the control panel remember the original URL of the image, which combined with settings sync means if you log in to a fresh account your background would be downloaded ;-) Then of course there's the slideshow background from my photoset/tag feature... That's the idea. :-) Havoc -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Online Desktop, Tomboy, and user storage (was Re: Dogfood servers now up)
On 8/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. * * * Warning, boring details follow: * * * My test instance of Tomboy is 96 notes; the average Tomboy user probably has less than 500 notes. On the server where I am synchronizing those notes, I am using 432 KB. So I think 10 MB would be sufficient for most Tomboy users. Each note is stored in a separate .note file, which is just XML (typically 0.6-4.0 KB). For our file system sync backend, typical synchronization server layout looks like this (semi-inspired by svn repository layout, though don't be fooled...we are only storing the most recent revision for each note, there is no saved history): server-root/ manifest.xml - (maps notes to revision numbers) 0/ - (contains directories for revisions 0-99) 0/ - (contains notes from revision 0) x.note y.note 1/ - (contains notes from revision 1) z.note ... 1/ - (contains directories for revisions 100-199) 0/ - (contains notes from revision 100) ... A user can point to any path on their file system to use as a server (an nfs or smb mount, for example), or for WebDAV and SSH we automate the process using FUSE file systems wdfs and sshfs. The architecture for building sync service backends is pretty flexible, and third parties can develop their own using our addin architecture. Maybe we should also consider a web page to access your notes, which would let you get to them from a random internet kiosk and the like. This would be awesome and I have some sketches of what this might look like (plus we already have xsl transforms for exporting notes to HTML). But I don't think we have the resources to work on this before the end of the current cycle. For a small quota we can support quite a few users without too much trouble. Think a reasonable hard drive (200G) divided by a 10M quota. As mentioned above, that should be quite reasonable. Something to consider, on the server we can store files or we can store database tables. They both have some advantages, with the database tables we can do fine-grained change notification over XMPP and it's easier to support a web view and web editing. With files it's easier to deal with large (exact definition fuzzy) data. I need to read more about the data model design in Mugshot. But I can say that with regard to this cycle, the Tomboy team can't add support for any new sync backends that don't have a corresponding FUSE file system. If online.gnome.org can provide WebDAV access, we can very easily add support. Otherwise, we'll have to wait until September to start work on it. Of course, patches are always welcome. ;-) So to sum up, if Mugshot can provide free WebDAV shares for each user, then the basic needs are set for Tomboy synchronization. Awesome ideas for the future: * Web app for viewing notes, making notes public, viewing friends' notes, printing notes, and downloading arbitrary notes for inclusion on your local Tomboy instance * More generic API for note data transfer, so server can store data however it likes and user doesn't have to worry about installing wdfs, configuring FUSE, etc. These are all things I'm psyched to work on; just let me know what I can do to help! Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Alberto Ruiz wrote: Errr... have you seen the link at the bottom of my previous e-mail? Anyway, direct link to the screencast: http://youtube.com/watch?v=reB9TNRQ1Bg Cool! Havoc ___ 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 (was Re: Dogfood servers now up)
On 8/2/07, Sanford Armstrong [EMAIL PROTECTED] wrote: On 8/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. I agree with Sandys asessment on the need for this. When I looked into writing some kind of .Mac equivilent for Conduit to use as a central store to sync stuff with I inevitably came back to the same point, why write my own backend anything when things like WebDav and gnomevfs support for it already exist. According to http://live.gnome.org/OnlineDesktop we will basically store account info for people and the services they use. I dont think reinventing the wheel and writing a server side backend to store generic use data is all that effective use of time (putting aside concerns like bandwidth, storage space and security for the moment). Why not use apaches WebDav support and have it authenticate against online.gnome.org. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libnotify
On 8/1/07, Christian Hammond [EMAIL PROTECTED] wrote: In the meantime, I'll ask the same question as I did before. Can we just consider libsexy or notification-daemon a blessed dependency given how widespread they both are these days? +1 from me. It's so widespread already that the number-of-libraries issue seems like it's now a moot point, at least to me. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Solving password/key security when 'The World is your Computer'
Just in case anyone is thinking of the same issues. A lot of discussion is going on along the lines of getting a user's desktop unbound from a physical computer, and letting the user peruse his/her settings, data from all over. One issue is that of passwords and (private) encryption keys. It seems it's poor security to let this data be stored on some server accessible from anywhere and protected only by a password. The idea is to store passwords and/or encryption keys on a removable disk (such as a USB thumb drive) and allow our user to have them available when it is inserted into a computer. [1] Gnome Keyring already supports this for passwords, and by GNOME 2.22 should support SSH and other keys in this manner. Obviously this isn't a solution for those with special security needs. But those folks should be using a single machine anyway. Cheers, Stef Walter [1] The machine needs to be free from malware or trojans. But that's the case with any computer you entrust with access to our data (whether stored online or not), passwords etc... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
