Re: How to submit patches for gnome-control-center and gnome-settings-daemon
Przemo Firszt prz...@firszt.eu a écrit: What about submitting patches using git send-email (default method for linux kernel). Is it possible? I'd say it depends on the particular GNOME sub-project . The Nemiver Debugger sub-project, for instance, happily accepts (and even prefers) patches sent to its mailing list. But it's true that most GNOME project maintainers prefer dealing with patches in bugzilla. Cheers. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Porting GNOME to Wayland
stefan skoglund(agj) stefan.skogl...@agj.net a écrit: I dont think Redhat wants The correct way to write it is Red Hat -- not Redhat, nor RedHat or whatever. Thank you for keeping that in mind in your future messages. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Bugmail: Gmail threading finally working!
Andrea Veri a...@gnome.org a écrit: I introduced a little fix yesterday night that will modify how bugmail's subjects appear, that for Gmail's threading to work properly. (as you may know Gmail doesn't look for the In-Reply-To: header but for the subject instead) Whoah! The proper way to handle this would be to have Gmail actually support the 'References' header. It's surprising to hear that in this day and age Gmail won't support that header. Have people tried file a bug report against Gmail for that? Just curious. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash
Philip Withnall phi...@tecnocode.co.uk a écrit: Are there any reasons against putting UTF-8 characters in the source code (which weren’t covered in my blog post)? Sorry, but which blog post? -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash
Philip Withnall phi...@tecnocode.co.uk a écrit: On Wed, 2012-12-12 at 17:35 +0100, Dodji Seketeli wrote: Philip Withnall phi...@tecnocode.co.uk a écrit: Are there any reasons against putting UTF-8 characters in the source code (which weren’t covered in my blog post)? Sorry, but which blog post? This one, which I linked to earlier: http://tecnocode.co.uk/2009/10/01/unicode-in-gnome/ Thank you. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Bugmail: Gmail threading finally working!
Jasper St. Pierre jstpie...@mecheye.net a écrit: Various people have documented why the header is broken, and thus why gmail doesn't care about or use it. I'd be interested to learn about the rationale behind that. Until then, I still think that honouring reply-to and references headers (which are the standard way to handle threading) would have made the issue Andreas was trying to solve mostly irrelevant. After all, my email client and many others (including Outlook!) can be taught to honour those headers just fine. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Bugmail: Gmail threading finally working!
Jasper St. Pierre jstpie...@mecheye.net a écrit: So, one, GMail's Conversation View *isn't* threading. Well, so it should support thread too then. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.6 Blocker Report
Andre Klapper ak...@gmx.net a écrit: === GTK+ === I'd suggest this Gtk+ bug be added to the list: [Bug 661973] gtk+ reacts on F10 press incorrectly It makes some useful applications be hardly usable using the keyboard :( -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Patryk Zawadzki pat...@pld-linux.org a écrit: The question is whether the freedom is more important than productivity of course. I'd rather keep the Freedom, and encourage people to work on improving the productivity in the realm of that freedom we fought so hard to get. I mean, we could imagine asking the board to help us support a Please Host a GNOME initiative, inviting people to donate to support gitorious or, if their infrastructure doesn't have a good enough availability track record, help to build up gitorious instances on our own servers. Of course, doing something like that would be less convenient than just going to github, but that is the high road that I figure the great GNOME community I care about would take. Until now, we have striven to make the right choices, not necessarily the easy ones. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Milan Crha mc...@redhat.com a écrit: On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote: --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer [...] the above help string might then just suggest that I would rather define my own --enable-maintainer-mode when I want to cover more things under it. If you do so, please don't call it --enable-maintainer-mode. I agree with Ross here. This is an option with confusing enough semantics, so please don't overload it more than it ought to. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Denis Washington den...@online.de a écrit: True. As I said, I'm not looking for configurability, but for an overall solution that allows to both suspend and power down. And to hibernate, please. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Formal complaint concerning the use of the name System Settings by GNOME
Matthias Clasen matthias.cla...@gmail.com a écrit: I don't think Shauns proposal addresses the issue, really. Why? Do you have an example that would show where Shaun's proposal falls short? If you want an app to be usable in different environments, then there are some good solutions: - make sure the app is self-contained and manages all of its settings itself - make your app smart enough to pick up the relevant settings from the different environments you want to support And there are bad solutions, including: - making the app drag along half of its original environment, via dependencies You don't say why these would better address the issue here and now in comparison with what Shaun is proposing. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Formal complaint concerning the use of the name System Settings by GNOME
Denis Washington den...@online.de a écrit: Am 23.07.2011 11:54, schrieb Giovanni Campagna: Il giorno sab, 23/07/2011 alle 11.27 +0200, Dodji Seketeli ha scritto: Matthias Clasenmatthias.cla...@gmail.com a écrit: I don't think Shauns proposal addresses the issue, really. Why? Do you have an example that would show where Shaun's proposal falls short? You have two .desktop files, matching the same application, so it is possible gnome-shell, unity or kde could pick the wrong one when matching desktop files to windows (unless you tweak Exec to pass --class, but that fails again with single-instance applications) But one of them is hidden via [Not]OnlyShowIn. There should be code in all desktop's .destkop file matchers to prefer the files tailored to the respective environment, and if not, it is easy enough to add. Exactly. I think everyone here agrees that this more a less a temporary measure and that other long-term solutions such as better cross-desktop settings integration is in order. I couldn't agree more. Giovanni Campagna scampa.giova...@gmail.com a écrit: [please don't CC me in your replies. I am subscribed to at lease one of the lists in the To: field] If you want an app to be usable in different environments, then there are some good solutions: - make sure the app is self-contained and manages all of its settings itself - make your app smart enough to pick up the relevant settings from the different environments you want to support And there are bad solutions, including: - making the app drag along half of its original environment, via dependencies You don't say why these would better address the issue here and now in comparison with what Shaun is proposing. You get to configure your apps once for both Gtk and Qt apps, which is better for the user and makes the system more consistent In particular, I underline Gtk and Qt: you don't write GNOME apps, and you don't write KDE apps, you write Gtk and Qt (or Qt+kdelibs) apps, and then the toolkits adapts themselves to the environment. If you can write a Qt+kdelibs app that work on windows or mac os x, you can make it work out of the box in GNOME, without dragging in the entire workspace. You forgot the here and now part in my question. You just can't do what Mathias is proposing /quickly/ enough. It would seem to me that we need a stop gap measure now, while we carefully think about something more streamlined and future proof to be crafted later. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Formal complaint concerning the use of the name System Settings by GNOME
Emmanuele Bassi eba...@gmail.com a écrit: On 2011-07-23 at 11:27, Dodji Seketeli wrote: Why? Do you have an example that would show where Shaun's proposal falls short? it falls short in showing: System Settings KDE System Settings under Gnome, and: System Settings Gnome System Settings under KDE. Oh, I see. the real solution is to make it unnecessary (or even conflicting) to install the KDE system settings shell under a Gnome environment, and the Gnome system settings under a KDE environment; That would be a more elegant situation, IMO. these are configuring the system settings, and you can hardly have two systems running at the same time on the same machine. Agreed. applications should not be configured through the *system* settings; and both system settings shell should configure the same services. This makes sense to me. You don't say why these would better address the issue here and now in comparison with what Shaun is proposing. there is no here and now — that would be a hack. I hardly think we have to solve this *quickly*, so we should solve it correctly. My point was to have the options written down and have interested people explicitly say why a particular point is valid or not, rather than just bluntly dismissing someone's point as being a non-solution without providing rationale. As for the here and now, I don't personally perceive this issue as urgent as I use GNOME only. But I could imagine that some people do. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Colin Walters walt...@verbum.org a écrit: I would really love to see someone set up official logging of GNOME IRC, like MeetBot or whatever. Several people run private loggers, but we'd just need to make clear to participants that it is being publicly logged. If IRC logs are posted somewhere, then there should be a communication channel available for people who couldn't attend the IRC session to raise comments and expect answers from the stakeholders. I believe a mailing list, shadowing the IRC channel would be a good enough way for this. Subsequently, the IRC logs could then be automatically posted to the mailing list, allowing people to chime in raise comments. Just my 2 cents. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome 3
Jan de Groot j...@jgc.homeip.net a écrit: On Sun, 2011-04-17 at 08:45 +0530, Nirbheek Chauhan wrote: This is why I think GNOME should start a marketing campaign of Awesome Hardware which is known to work flawlessly, and Sadface Hardware which is known to work, but with glitches. This can help users make informed choices while buying machines (or building them), and would help us improve hardware support for Linux as well. In most cases, it's just the last 1% that's left. With linux it's impossible to support such a list. Things that work perfect on the kernel you test with will be broken two versions after that. The issue is not just limited to kernels, but also to manufacturer BIOS versions, xorg-server, the video driver and mesa. If you add binary drivers like nvidia or fglrx to that list, things become even more complicated. If some people are willing to maintain such a list, I believe they should not be discouraged, to say the least. There are similar pages somewhere on the interweb targeted at laptops and they did help me quite a bit in my buying choices. Having your hardware not well supported just because of a bug in a certain version of the kernel is not the same thing as having it not supported because the manufacturer doesn't provide Free Software drivers. In the former case you can get away with e.g, selecting a given version of the kernel and in the latter case you are just asking for troubles if you buy such a hardware. I understand the complexity of adding non-free divers to the testing matrix, but is that really a problem? Why not just considering Free Software drivers? Would that be _that_ surprising, coming from us? -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome 3
Sam Thursfield sss...@gmail.com a écrit: Suspend and hibernate are both hacks around the fact that power on and power off take a long time and that our session manager doesn't save session state. This seems to be an over-simplification to me. Processes managed by the session manager are just a part of what comprises the user's working set. And of course, there are users who use things that are independent of a particular session manager. In other words, the scope of the feature which purpose is to save the global working set of a user is by essence broader than just the one of our session manager. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
Christopher Roy Bratusek zang...@freenet.de a écrit: especially Emanuelles It would be a good start to spell Emmanuele's name correctly. Just my 0.1 cent. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
Benjamin Otte o...@gnome.org a écrit: [...] Hrm, in 90% of the cases where I need information about why changes were made, I need git blame/cvs annotate style output, and a ChangeLog cannot give me this information. (Also, the tools to filter ChangeLogs suck, or are there equivalents to git log -- $file?) When you have the git metadata around it sure is extremely powerful. I don't object that. So I think it would be a lot better if instead of just generating a ChangeLog, we would ship the full git history in the tarball. That way you have a history that is as useful as possible. Heh :-) I am not asking that much. Beside the size related implications I figure people would point out, I like to see tarballs like a DVCS-neutral way of distributing source code; as such, I wouldn't ask for shipping git history there. It's hard for me to put my git-fan-hat off but I believe there are times when such a sacrifice becomes appropriate. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
Emmanuele Bassi eba...@gmail.com a écrit: *if*, on the other hand, you want a ChangeLog because it makes your life as a packager easier (for some unknown reason) then you should probably ask for a Gnome Goal to add the autogeneration of the ChangeLog from the Git commit log to every GNOME project. the patch is trivial and I'm pretty sure it could also teach people a thing or two about auto-tools. This would be awesome, as far as I am concerned. I personaly find ChangeLogs quite valuable for situations where people have the source packages (like a distribution DVD) but not necessarily an access to the internet and want to understand when/how something changed. I found myself in such a situation not very long ago and I was very happy to have a proper ChangeLog around. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le lundi 26 avril 2010 à 17:18:31% (+1000), Andrew Cowie a écrit: but the whole point of decentralized VCS is disconnected operation and having to have an active internet connection to get to some centralized website in order to follow through workflow is a non-starter for most of us. I agree, FWIW. I prefer dealing with patch review through simple email for that reason. It's so much easier to just do the review offline. It would be interesting to find a way to make these tools -- bugzilla or whatever patch review system -- be interoperable with email. If I could just get patches attached to GNOME bugzilla bugs in my email, reply to those via email and have those properly appear in bugzilla comments, that would be great for me. Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le lundi 26 avril 2010 à 21:24:19% (+0200), Siegfried-Angel Gevatter Pujals a écrit: 2010/4/26 Dodji Seketeli do...@seketeli.org: It would be interesting to find a way to make these tools -- bugzilla or whatever patch review system -- be interoperable with email. Launchpad supports answering to merge requests by mail (as well as managing bugs, etc). I guess It would be useful that GNOME bugzilla supports this too. Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
Le sam. 03 avril 2010 à 14:52:50 (+0200), Josselin Mouette a écrit: As things are going, you are leaving us no choice but to keep shipping gnome-panel by default for a very long time, unless we want to provide two radically different user experiences. I agree with this. I would guess that we (as a project) just have to make it crystal clear in our communication that there is ought to be a transition phase that can probably be long. This is important to ensure that users and application developers expectations are not over inflated. Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomas Frydrych a écrit : Josselin Mouette wrote: I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. I think that is a wrong way of looking at it; we are going to be shipping one, unified desktop environment with a particular set of HW requirements. In addition to this it will be possible to downgrade this to the older Gnome desktop environment for legacy HW that does not meet the requirements. I couldn't agree more. Furthermore, this is already the case today. The GNOME based environment running on my N810 tablet is different from the one I run on my big iron desktop machine. And I find that very cool that we can have different flavors of GNOME tailored for different HW capabilities - if, of course, we can afford it. I am not sure users are complaining about that state of things today. D. - -- Tant que l'on n'a pas la tête coupée, on peut espérer mettre un chapeau. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iEYEARECAAYFAkngjAAACgkQPejI7lrem2HQFwCggYVwEx+2iOKTrR0KJfcfH4nd YFgAn0g2TzuBnhqRpUJHScQrybrSCemv =FPXT -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Calum Benson a écrit : I guess the other category here is the current generation of thin clients... not 'legacy hardware' by any means, they just aren't really designed for this sort of thing. Then why not just run the current metacity + gnome applet combinations of today on that hardware ? Assuming metacity + current gnome applets are not going to vanish all of a sudden. Of course, that would result in more work for distributions because they'll have to propose the new GNOME Shell setup as well as a poor man setup. Now the resulting question would be, are distros ready to make that effort ? Dodji. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: indentation of c code
BJörn Lindqvist a écrit : [...] There is no GNOME standard for indenting C code -- every project use their own indentation style (unfortunately). But to reformat a file to an indentation style many projects use, you can just run indent without any arguments. I am sorry, but I think there is a GNOME standard for indenting C code. It's at http://developer.gnome.org/doc/guides/programming-guidelines/book1.html, chapter http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html. If GNOME C projects use their own indentation style, I think it's just because only a few people have read that documentation or because GNOME as a project does not enforce it that much. GTK+ uses the GNU indentation style that is documented at http://www.gnu.org/prep/standards/standards.html. Best wishes, Dodji. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autogen.sh failure and AC_CONFIG_AUX_DIR
On Fri, 9 Nov 2007 15:23:40 +0100, Pascal Terjan [EMAIL PROTECTED] wrote : [...] So, the fix I proposed is to add AC_CONFIG_AUX_DIR(.) in configure.ac After 2 months it looks like nobody is interested in this issue... What should I do ? Open a bug on each module and hope most maintainers will accept the fix ? That's tedious to do, but it seems it's would be the most efficient thing to do, I am afraid :-\ /me cheers pterjean up. -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On Sun, 23 Sep 2007 13:41:10 +0200, Xavier Claessens [EMAIL PROTECTED] wrote : Le dimanche 23 septembre 2007 à 13:24 +0200, Vincent Untz a écrit : Le dimanche 23 septembre 2007, à 10:59 +0200, Xavier Claessens a écrit : - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. That's an interesting debate. Will the interface of empathy make it easy to call phones mobiles? I'm not quite sure ekiga and empathy fill the same role. We already have SIP implementation and I think it works on the N800. Empathy just lack of UI for voice/video calls but I'm working on that atm. I'm not sure telepathy-sofiasip and farshight are as complete as ekiga but I'm sure work is being done by nokia/collabora to improve that. I almost never used ekiga myself. As I understand it, libempathy is a set of reusable widgets and leverages on the telepathy framework. That implies that nothing should prevent Ekiga from using libempathy/telepathy at some point in the future when it is stable and and has the necessary features. Today, a lot of people are using Ekiga because it *works now* for the softphone use cases. SIP and H232 (yes people are still using that one) are complicated in the sense that just claiming supporting the specs is not enough. You really have to debug your implementation against the buggy behaviours of the servers that are *already* out there in the real world. In that respect, I think that Ekiga is way more mature today than Empathy. Please correct me if I am wrong here. Empathy/Telepathy does look really promising though and I think the nice thing would be to see some kind of integration work going on at some point. I mean, one could imagine some telepathy-opal initiative to take place where necessary, or seeing Ekiga re-using some libempathy stuff at some point. Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtkmm as a dependency
On Mon, 9 Apr 2007 19:32:30 -0600 Elijah Newren [EMAIL PROTECTED] wrote: This made our decision on the topic at the recent release-team meeting very easy. :-) gtkmm is now allowed as a dependency. What a nice easter present :-) -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using C++ bindings for desktop/admin/devtools modules
On Fri, 16 Mar 2007 15:53:58 -0500 Shaun McCance [EMAIL PROTECTED] wrote: We do actually already have C++ in the desktop with Epiphany, although that C++ code is limited to the Mozilla embedding, which you can't exactly get around. Ekiga is also written in C++, although not based on gtkmm. So the question is, do we want to allow programs in the desktop that are written entirely in C++? It would be nice to send a positive signal to the c++ developers sitting out there :-) If so, then it would be silly to forbid them from using gtkmm. Amen brother. Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using C++ bindings for desktop/admin/devtools modules
On Fri, 16 Mar 2007 15:53:58 -0500 Shaun McCance [EMAIL PROTECTED] wrote: We do actually already have C++ in the desktop with Epiphany, although that C++ code is limited to the Mozilla embedding, which you can't exactly get around. Ekiga is also written in C++, although not based on gtkmm. So the question is, do we want to allow programs in the desktop that are written entirely in C++? It would be nice to send a positive signal to the c++ developers sitting out there :-) If so, then it would be silly to forbid them from using gtkmm. Amen brother. Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed suite: developer tools
I might be stupid but Vermine reversed would be enimrev? Heh. No. What you say is not stupid :-) What I reversed is not the string of characters, but the string of syllables (or phonemes, if you prefer). I agree Syllables are hard to define because their definition is at least language specific. But well, this is also part of the beauty of human languages. It's impressive to see how various the kinds of discussions on desktop-devel-list can be. Cheers, Dodji. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A Framework for Desktop Syndication
Hello, This sounds like a good idea to me. Maybe you should bring the developer of applications like liferea into the loop. There is certainly something to be shared with them. This kind of API could simplify the code base of apps like liferea and allow other applications to provide syndication to their users, at a very low development cost. Dodji. On 6/17/06, Yaron Tausky [EMAIL PROTECTED] wrote: Hi, I've been thinking about implementing a new framework, to abstract the use of various syndication formats on the desktop. It would consist of a daemon that registers feeds over D-BUS and reads them at specified intervals, and clients which will be able to tap into the daemon's database and get notifications about new updates. The intended use is for reading blogs, news sites, podcasts, etc. Another possible use I can think of is to aggregate software updates notifications. I'd like to hear your opinions on this concept -- whether you think there is a need for such a framework, have another use case, or perhaps if you think this is all rubbish. :-) On a side note, I'm not an experienced GNOME developer, and since this seems like a rather simple project to implement, I hope I'll be able to do it by myself. My motivation is the feeling that feeds are not integrated enough into the desktop -- I'd like to improve this state. -- Yaron Tausky [EMAIL PROTECTED] ___ 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
