PDF library (was: Re: (L)GPLv3)
On Thu, 2010-07-08 at 19:45 +0200, Christian Persch wrote: I can't be the only one who was excited about discovering there's a LGPL3+ pdf library out there! I work a bit on evince, and I had never heard about it. However, the excitement was brief, and terminated by actually checking out the code... What about PoDoFo? It is LGPLv2+ and allow read and write PDF, which would allow editing. It does not have a renderer though, but that's what I would start from if I needed. Just wondering. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On 07/10/2009 12:45 AM, Joone Hur wrote: Is proprietary OpenGL/ES libraries applied by this exception? Maybe you should ask your lawyer, since you seem to expect legal advice. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 status update
On 06/20/2009 10:15 AM, Andre Klapper wrote: * GSEAL: http://bugzilla.gnome.org/show_bug.cgi?id=585391 To Do: A lot. Developers please start taking a look at this. GSEAL has a few outstanding bugs open that make its use impossible. http://bugzilla.gnome.org/show_bug.cgi?id=562937 To me that one is a show stopper. Non withstanding the fact that some very common accessors like gtk_widget_get_window() are 2.14 only which is a very big annoyance for people we who / need to maintain compatibility with older version (look at what some enterprise distro or devices ship, like SLED10, RHEL4, Maemo). Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
On 05/29/2009 09:05 AM, Frederic Crozat wrote: As a side note, another reason developers are currently abusing notification area is that is it the only cross-desktop (GNOME/KDE/LXDE/XFCE/IceWM/insert_your_favorite_de_here) way to get applets-like icons on a Xorg system, which also have the nice pro to not pull something as ugly as bonobo in the loop. So, if we really want to improve the situation for GNOME 3, we should also try to solve this cross-desktop missing API for applets. Also the KDE people have developed a new spec for Status Icon that is apparently more versatile, and would love to see it implemented in GNOME. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving gdl from Development into Desktop
On 05/27/2009 10:33 AM, Johannes Schmid wrote: Hi! Is there any reason this functionality couldn't make its way into GTK+? Hmm, I though about answering this question in the proposal... Well, I think it's not ready for adoption in gtk+ because it's not widely used. It is not widely used because it is not in Gtk. catch-20 Second, I think it can lead to creating HIG-unfriendly apps if not used carefully and I think it is only useful for a small number of applications. We can do that with stock Gtk too. The proper solution is to write that part of the HIG to take Gdl into account. Third, I don't think there is a big chance to integrate such a big codebase in gtk+ regarding the other bigger patches I submitted to gtk+ (EggToolPalette, GtkNotebook widget-in-tabspace, etc.). *sigh* seriously this is another problem. So, to conclude, I think it's better to have it in Desktop for now and think about inclusion in gtk+ later for 3.0 or 3.2. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On 05/26/2009 08:48 PM, Lennart Poettering wrote: The initial Apple implementation of mDNS/DNS, which was Rendezvous (later renamed to Bonjour) was licensed under APSL -- which is not a Free Software license. Not to remove any argument, but for the sake of accuracy, it should be noted that APSL 2.0 is Free Software, according to the FSF: http://www.gnu.org/philosophy/apsl.html Albeit APSL 2.0 is not compatible with the GPL (like the Apache v2 license isn't compatible with GPLv2), which is a problem when it comes to GNOME. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: TARBALLS DUE: GNOME 2.26.2 Stable Release
On 05/15/2009 03:53 PM, Behdad Esfahbod wrote: Don't you know that Monday is a bank holiday in Canada?!?!?!?! More time for hacking :-) Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
In the prior discussion, there was a lot of discussion as to GJS v. Seed. Since then, compatibility between the two has improved a lot, notably with Seed adopting GJS's imports system. At this point, most GJS code could be pretty easily ported to Seed. Porting Seed code to GJS might be a bit more difficult, due to some things like Seed making pervasive use of GObject. It is more or less possible to write code to a least common denominator of the two. In addition I believe it would be possible to port GNOME Shell to Seed, with no more than a few days work. So in the botton line, what make Seed more suitable than gjs? Does that mean there is a committment to only use the selected JS engine for modules in GNOME? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On 05/12/2009 08:01 PM, Robert Carr wrote: For 2.28, it may make sense to have both gjs and Seed as modules, and try and keep code somewhat compatible. It's still not entirely clear which JavaScript engine is going to end up being better long term, so we might not want to completely commit to one yet. With that plan, it is -1 from me. 2 engines is one too many IMHO. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
On 04/02/2009 02:39 PM, Rob Taylor wrote: My question would be is why do these People have a desktop in which there isn't a DBus session bus? The case were people in corporate Microdows environment have to manage a Linux box, and have to run UI application to the X11 server on the Windows PC they use to do that. In that case you don't have a session. FWIW, my Debian server does not have dbus running. I never use any X program from it, but I wonder how it would behave in that situation. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
BugBuddy uselessness
Hi In GNOME 2.24 and up, BugBuddy no longer send the crash reports to Bugzilla. It send them to a misterious crash.gnome.org, and the URL returned by bugbuddy to the user leads to a 503 error. Example: http://crash.gnome.org/report/index/8d6249b4-f79f-11dd-8569-0007e9333148?date=2009-02-10-18 Is there any plan to remove Bug Buddy now that it has been made useless? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BugBuddy uselessness
Mathias Hasselmann wrote: Am Mittwoch, den 11.02.2009, 12:00 -0500 schrieb Hubert Figuiere: Hi In GNOME 2.24 and up, BugBuddy no longer send the crash reports to Bugzilla. It send them to a misterious crash.gnome.org, and the URL returned by bugbuddy to the user leads to a 503 error. Example: http://crash.gnome.org/report/index/8d6249b4-f79f-11dd-8569-0007e9333148?date=2009-02-10-18 Is there any plan to remove Bug Buddy now that it has been made useless? Your reasoning is strange. Wouldn't it make more sense to fix crash.gnome.org? Or did we gave up on software quality? My reasoning is that it is broken. Then I ask question. Before it did submit to bugzilla and it worked. Now it submit somewhere and it doesn't. If fixing crash.gnome.org is the solution, then be my guest. I don't care either or, as long as it works. But it hasn't been for a few release. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Tue, 2009-01-06 at 03:46 -0500, Behdad Esfahbod wrote: So, here is what I'm bringing to the table: I'm volunteering to work with interested fd.o admins and other volunteers to switch GNOME to git. I need to first go check to see if I can secure enough time to lead this, and if I can get enough peoples' attention to make this happen in a timely manner. I will make an official proposal when I figure those out. Given the nature of the GNOME repositories, ie 1 repository per module, and the fact that we have a list of core modules for the various suites, it could be useful to do this one by one using a few volunteers project. In that case I volunteer the one I maintain, namely raw-thumbnailer and niepce[1] to switch them to git. It would allow to have the infrastructure setup and tested while still not blocking GNOME itself from its development pace. Just my 2¢ Hub [1] and for that last one, actually I'd love to fix its history as that SVN export/import totally foobared it, long story short, because subversion is deficient in disallowing import/export without shell access. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Eel merged into Nautilus 2.25.3
On Mon, 2008-12-15 at 19:43 +0100, Alexander Larsson wrote: I just released Nautilus 2.25.3 which contains an internalized copy of eel, and I don't plan to do any more eel releases. This lets the compiler do better optimizations and means one less library to link against. Eel was always unsupported and shouldn't be used outside nautilus. However, some applications still does this. These apps will work against the last eel release, but should really work towards removing this dependency. Or maybe work on moving the usefull features of EEL to Gtk+ Like the application chooser. I have a patch for Firefox to use that instead of the infamous file selector in /usr/bin. Actually one part was copied from nautilus, the other linked against EEL. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, 2008-10-28 at 17:55 +0100, Patryk Zawadzki wrote: Lies! We should totally be using a shared DropBox account with all the GNOME inside! ;) Fall back to the BitKeeper effect[1]? No thanks. Hub [1] DropBox is not Free Software. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote: I just commited some nautilus code to trunk (for 2.25) that makes use of libunique for unique application functionallity (replacing the previous code using bonobo-activation). However, libunique isn't currently a blessed external dependency. So, I'd like to propose it. (Another alternative is to put a cut-n-paste copy in nautilus as fallback, its not a large piece of code anyway.) Can't we add that to Gtk+ ? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On Mon, 2008-07-28 at 00:31 +0200, Vincent Untz wrote: Some update about those items (correct me if I'm wrong): + about features stability: feedback is welcome. Xavier will probably send an update. + the keyring is now used (afaik). It is my understanding that the problem lied in telepathy-mission-control, and the latest versions of mission control do indeed use the keyring. + I believe that the plan is to slowly move the empathy libraries into telepathy and that code might get rewritten for this because of LGPL needs. Only a promise so far, though. This might mean we should only consider the empathy application for inclusion (and try to forget about libraries). I think it is important to consider it just as an application. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Fri, 2008-06-27 at 00:05 +0200, Rodrigo Moya wrote: of course, instead of supporting XSMP, we could try to get KDE use William's new implementation Even that will take time. They still have a lot of work to finish porting apps to KDE4[1]. So while this is a good idea, it should be made sure that support for XSMP still stay around for quite a long time. Hub [1] don't take this as a troll. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, 2008-06-21 at 11:57 -0500, Jason D. Clinton wrote: 2. The Giant Rift in the Gnome community over Mono has to end. I hate Mono as much as the next guy but it's quite apparent now that some really cool stuff with financial backing from Big Linux Distributor is not going away: Gnome Main Menu, Banshee, F-Spot, Beagle, Tomboy, etc. We have to get rid of the rift and bring the two diverging communities back together. Whatever damage that might incur in the minds of the Slashdot crowd has already been done--Gnome is perceived (rightly or wrongly) to be largley 'infested with Mono' in the minds of our critics. We cannot capitulate on this to appease a vocal minority of users that detest Mono. It's obvious it's not going away and, with a trivial amount of work, we can mend the rift by including the afore-mentioned mondules in our official releases. Let's just do it and move on with our lives. I don't see what Gnome Main Menu is doing in your anti-Mono rant. Or maybe you are and editing contributor of BoycottNovell.com and decided to spread the misinformation here where people actually tend to know what they are talking about. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, 2008-06-21 at 14:26 -0500, Jason D. Clinton wrote: I can see how it could be taken that way. I also see now that Beagle has become an optional dependency of gnome-main-menu. Apologies for the confusion. Oh no. Not that uninformed libbeagle rant again. libbeagle NEVER bring Mono as a dependency, and never has. Hint: beagle has been uninstalled on every of my openSUSE machines. And I didn't recompile anything Hub ___ 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.24
On Fri, 2008-06-13 at 17:35 -0500, Jason D. Clinton wrote: (I haven't said anything during the 2.24 release cycle. I just reviewed the application as it stands at version 0.23.1 and I believe that it simply is not ready to be included. Perhaps in 2.26.) Not to be picky but you are already 2 version behind. That's good to have an idea of its state. http://ftp.acc.umu.se/pub/GNOME/sources/empathy/0.23/ 0.23.3 is the latest. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new external dependency: libview
On Thu, 2008-05-29 at 03:00 +0200, Étienne Bersac wrote: libview has some interesting widgets that may worth entering Gtk+ (like FieldEntry, Header, etc.). Other should be merged inside Gtk+ itself (DeadEntry, ContentBox, UndoableTextView, etc.) Except that FieldEntry, Headers, DeadEntry, ContentBox and UndoableTextView are implemented using Gtkmm, in C++. This would cause a circular dependency between Gtk+ and Gtkmm. Nonwithstanding that I doubt that C++ code would be acceptable in the Gtk+ codebase. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: off topic; HELP! I cannot create a terminal window in gnome.
On Sun, 2008-05-25 at 20:26 -0600, Ralph Boland wrote: Sorry for not being a development issue unless you consider modifying gnome so those stupid enough to do what I have done can't do it anymore. since you know it is off-topic why do you post it? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Thu, 2008-05-15 at 11:19 -0500, Federico Mena Quintero wrote: C is hard. Unicode didn't exist in the 1970s. Get over it. If you want UTF-8 strings in your source code without escaping non-ASCII chars, use C# or another modern language which supports that. utf-8 encoded litteral DO work in C, without glitch. The problem is mostly the editors screwing this up. Hub ___ 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.24
It is not a problem of freedom but a problem of license compatibility. LGPLv2-only is NOT compatible with v3. Let's not make mistakes and anticipate. The move to (L)GPLv3 is unavoidable, even though it is not instant. Then it's not an issue; it's a preference. Are you going to threathen existing LGPLv2 projects to remove them from GNOME? There is no threat. Why do people have to be so agressive when we start talking license? It is merely my only opinion. Remember, I have NO power (and don't pretend to have any). But opinions have been requested and I gave mine. Note that I was talking LGPLv2-only not LGPLv2-or-later which is used in most case. That's the -only part which is a problem. Now if you all find that it is not a problem, I wish you good luck. That'll just encourage me to relicense my own code to v3 faster :-) It IS an issue. Xavier has exposed a solution which seems to be satisfactory and that is by far easier than getting the original authors to re-license (I have my theory about the license choice, but I'll keep it to myself). Hub ___ 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.24
On Tue, 2008-03-25 at 11:50 +0100, Xavier Claessens wrote: libmissioncontrol = 4.53 libmissioncontrol is LGPLv2 only. This is a problem as it prevent Gnome to ever move to (L)GPLv3. That's a -1 solely because of that. Hub ___ 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.24
On Wed, 2008-03-26 at 12:11 +1100, Andrew Cowie wrote: On Tue, 2008-03-25 at 09:26 -0400, Hubert Figuiere wrote: libmissioncontrol is LGPLv2 only. This is a problem as it prevent Gnome to ever move to (L)GPLv3. So what? LGPLv2 is Free Software. That is sufficient in our view. Even more so because we are talking about the LGPL here. It is not a problem of freedom but a problem of license compatibility. LGPLv2-only is NOT compatible with v3. Let's not make mistakes and anticipate. The move to (L)GPLv3 is unavoidable, even though it is not instant. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help sanity check the release notes
On Wed, 2008-02-27 at 20:16 -0500, David Zeuthen wrote: Might want to mention, under Better Networked Filesystems, that we now support - cdda:// - audio tracks on Audio CD's are available as .wav files; and - gphoto2:// - for digital cameras that are not mass storage out of the box (though you may want to avoid technical terms like cdda:// and gphoto2://). These are pretty visible end user features; we didn't have this in upstream builds of gnome-vfs. Why not using camera:// ? And you could aslo add support for Mass Storage camera at the same time so that it be unified. Two way to do that: just rebind the mounted device or use the disk: driver in gphoto2. Note that we had a FUSE filesystem for a while, so it feels like NIH again and again. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Digital camera support (was: Re: help sanity check the release notes)
On Wed, 2008-02-27 at 20:37 -0500, David Zeuthen wrote: On Wed, 2008-02-27 at 20:28 -0500, Hubert Figuiere wrote: Why not using camera:// ? Because it might conflict with another camera gvfs backend we might want to add in the future? Using what? That would also mean applications wouldn't be able to use it as they would need to know about it. Nothing is being abstracted in the end. And you could aslo add support for Mass Storage camera at the same time so that it be unified. Two way to do that: just rebind the mounted device or use the disk: driver in gphoto2. Why would we ever want to do that? It would dog slow and the gphoto2 API is a bit craptastic; you can't do partial reads etc. etc. Besides, Mass storage cameras already work very well using the kernel mass storage drivers. Not if access the file system directly (which is the solution #1 I just proposed when I said rebinding). So far you are not making the application implementation easier as they'd have to distinguish one with the other. BTW your comment about libgphoto2 API are still being awaited on the gphoto-devel mailing list. For now it is a bit of an in your face gratuitous comment. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Tue, 2008-02-12 at 15:38 +0100, Alexander Larsson wrote: I'm not sold on the fact that there are many important regressions. The main regressions, in my mind, are the ftp backend, the network backend and the connect dialog. There might be some other regressions, but I've not noticed them. (well, there are also the themes and fonts backends, but they're clearly not blocker) Yeah, i also don't see the regressions as major. I mean, its not like gnome-vfs is bugfree. The reason we're going from it is because its problematic. I have to disgraee. I think they are. The end user is more likely to see these regression than any bug or design issue that gnome-vfs has. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extreme memory usage for gnome-panel related apps
And more generally, to have one VM per language type, rather than per app. So GNOME should be turned into a single address space with the kernel and X11. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extreme memory usage for gnome-panel related apps
On Sun, 2007-12-02 at 13:27 -0800, Ethan Osten wrote: Personally, I hate coding in C - I have better things to do with my time than to deal with things I don't really have to deal with. And I know there are a lot of people like me, or else PyGTK etc. wouldn't be so popular. Go back to C just isn't an acceptable option. You can use C++ :-) It brings speed comparable to C, very good interoperability with existing C code, compile time type checking, easy to use class system (compared to GObject), and good C++ binding (Gtkmm is even designed to be interoperable). Granted than the overall resistance from GNOME contributors does not help (most of it being pure FUD due to lack of knowledge). Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Lowering barriers
On Tue, 2007-11-13 at 16:34 -0600, Cody Russell wrote: It would be really sleek if we came up with a utility that could do this for Gnome/GTK apps, and I think it would lower the barrier for people to try to start developing. If we had something that worked like, say: ghack --python --docs --intl projectname I was thinking exactly something like that[2]. Bonus point if there is a point click version[1] Hub [1] not that I'd use the GUI, but I ain't the typical user either. [2] I'm not volunteering either to write it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build systems
On Fri, 2007-11-09 at 15:40 +0100, Dave Neary wrote: That said, there is one concern which trumps all others when choosing a build system: how easy is it for someone with a plain vanilla distribution to compile install your software? ./configure make make install is about as hard as it can be. any harder, and your barrier to entry is too high. That includes cd build; cmake ..; make; make install; (at least until it becomes ubiquitous). How does toc2 fare on this level? autoconf/automake are hard for the software developer, because the goal is to make it easy for the software builder. The trade-off pays off in community size, testers, developers and translators down the line. And in that casse, the requirement for autotools based is very low: only shell and the compiler + dependencies for said program (no need for the autotools if you just want to build). While for CMake based build, you need CMake to be installed first. Worse for CMake, often adding new features means fixing CMake (the KDE4 developers had to upgrade CMake on a regular basis, but maybe the madness stopped by now), while for automake you just provide the macros locally (ok automake seems to break compatibility making it a PITA to build gtk from SVN on a SuSE for example, but that's a different problem). I tried to use CMake last year to be curious, and it failed because of the lack of documentation. With autotools I discover new tricks every days, but most of them are just in the documentation that is widely available (unlike CMake). Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
OOo is Gtk based for several years. This is not true. OOo only uses Gtk themes, not Gtk widgets. Big difference. Like the difference between firefox and epiphany. What difference does it make to the users? It looks like it. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
On Thu, 2007-11-01 at 13:57 -0400, J French wrote: I hate OOo with a passion. It may be fine for Windows, but so many other applications are better under Linux. I was hoping there was something GTK-based for this as well. OOo is Gtk based for several years. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
On Thu, 2007-11-01 at 14:26 -0400, J French wrote: I would guess something that was written specifically for the Gnome desktop for presentations would have the same benefits. Nowhere I said it was written specifically for the Gnome desktop. BTW, AbiWord isn't either written specifically for Gnome, but it takes a different approach. Hub PS: I think this is really sliding off-topic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote: Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. What about using one of the already existing dependencies like libsoup or gnome-vfs? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On Tue, 2007-09-25 at 14:55 +0100, Ross Burton wrote: On Tue, 2007-09-25 at 09:41 -0400, Luis Villa wrote: New d-d-l rule: no one gets to say 'it is useful' without explaining their use case :) Luis (I believe you that you use it, but I can't for the life of me figure out why) Because project plans at work are often based on week number. Task foo has to be completed in week 38, this image was built in week 36, etc. But then you have to make sure week start right. Some consider week 1 starting January 1st (eventually being less than 7 days), some consider week 1 starting the first Sunday or Monday (oh another exception) of January. This is a major source of confusion that has to be taken into account for the design. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving libxml2 and libxslt to external dependencies
On Sun, 2007-09-23 at 14:15 +0200, Vincent Untz wrote: FAICT, the only other impact it could have on GNOME is for libxml++: should it stay in our bindings set or not? What do you all think of this proposal? I can't speak for libxml++ maintainer, but given that libxml++ depends on Glib::ustring, it should stay at most in the bindings. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git vs SVN (was: Can we improve things?)
On Fri, 2007-09-14 at 11:27 -0700, Sanford Armstrong wrote: For example, whenever we commit a patch in Tomboy, we mention the relevant revision number in a bug comment. If Bugzilla were smarter it might be able to do neat things with that, and we might come to depend on that feature. You mean like having a post-commit-hook that would parse the commit message that would say Fix #12345 to mark the bug 12345 in bugzilla as fixed with the commit message and revision # attached? That would be awesome IMHO. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git vs SVN (was: Can we improve things?)
On Fri, 2007-09-14 at 20:21 +0200, Olav Vitters wrote: On Fri, Sep 14, 2007 at 05:36:36AM -0700, Sanford Armstrong wrote: Yes, using a command called svndumpfilter. You'd have to not care about your revision numbers being resequenced. People care about that? I always renumber them. However, by default it doesn't. When using svnmerge, it stores the revision # already merged. That would break it if the revision are renumbered. Just my $0.02. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace scrollkeeper
So there you have it. Anyone want to volunteer an opinion, question, flame? Trollish, (but I'm honestly curious :)) why did you write it in C when there are many other languages around more suitable to the job? Since you are saying it is trollish and don't actually provide any argument, may be you should refrain from making flamebait comments like these. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sticky Windows
adel wrote: GNOME desktop needs something like this http://www.donelleschi.com/stickywindows/ You mean the big white rectangle with the green icon in the middle of the web page? That's very descriptive. Hub ___ 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
Vincent Untz wrote: Does it make sense to allow the use of gtkmm and other C++ bindings in our desktop/admin/devtools suites? It does, definitely. Hub signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Subversion migration finished
Ross Burton wrote: It would be nice if CVS were at least able to be used read-only, so that those of us with changes in our local trees, can ensure that we're up to date with the final point of CVS, and can generate diffs to apply against SVN when migrating local checkouts. It can. As the migration pages discuss, simply switch the CVS checkout to use the anonymous CVS Root. On my Debian based system I have 'cvschroot' that allow changing the CVS/Root for the tree. It is in a package named cvsutils It should be available in whatever distro you are using. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME git repositories?
Thomas Thurman wrote: 1) Launchpad already knows about all the GNOME projects. Would it be possible to use Rosetta actually on Launchpad just for the translation part of each project? (From my limited knowledge of Launchpad, I think it would.) Let's not repeat the BitKeeper fiasco. 2) Aren't they planning on freeing Rosetta eventually? Maybe suggesting that we would use it would push them over the edge? November 2005, in Montreal, Mark promised to do so Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Gnome-OCR] Integration of Tesseract-OCR...
Emmanuel Fleury wrote: 1) Tesseract-OCR software has been released under Apache License 2.0 This license is know to be incompatible with the GPL because more restrictive about patents: « Apache Software License, version 2.0 This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.) » Seen on: http://www.gnu.org/licenses/license-list.html What are the implication of this on the use of this software inside a GPLed project ? That you can't link a GPL program against a library contain such code. If it is to write an application for Gnome (even part of Gnome) but not having a library that use said code for the Gnome platform, it is not a problem. And the Apache License 2.0 is not incompatible with LGPL, which mean that it can link against Gnome libraries. And as stated earlier, GPLv3 should address the problem. 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
Jamie McCracken wrote: would suggest: Contact.HomeEmailAddress : [EMAIL PROTECTED];[EMAIL PROTECTED] Contact.WorkEmailAddress : [EMAIL PROTECTED] note using semicolon as delimiter so contents would need to be escaped for the semicolon. I guess standardising on semicolon delimiters might be a good idea? I would prefer: Contact.Home.EmailAddress : [EMAIL PROTECTED];[EMAIL PROTECTED] Contact.Work.EmailAddress : [EMAIL PROTECTED] Do be able to query EmailAddress indifferent or Work Contact information. Just my $0.02 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
Summary files that provide offsets into an mbox or individual references to maildir files seem like the sanest way to go to me. (And this is what both Evolution and Thunderbird do.) The real downside is that those summary files are considered private, and aren't designed with searchability in mind, which makes indexing the data inside very challenging. It was the approach used by Mail.app on MacOS X, but with Spotlight and MacOS X 10.4 they changed to a more proprietary format that was more convenient to index. How convenient when you are the master of the whole foodchain. If you can't go to the mountain, bring the mountain to you. And JWZ have been pissed about it too. References: http://jwz.livejournal.com/505711.html http://diveintomark.org/archives/2006/06/16/juggling-oranges 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
[ 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
Sebastien Bacher wrote: Le jeudi 19 octobre 2006 à 13:36 +0100, Jamie McCracken a écrit : We will be pushing for this in ubuntu edgy+1 Will we? Where has this been decided? If they need somebody to upload it to universe, I'll happily submit it :-) Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
JP Rosevear wrote: On Tue, 2006-10-03 at 18:33 -0500, Travis Watkins wrote: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. Very few desktop cards don't have 3D capabilities, More than you think: OLPC, thin clients, old machines, etc. Maybe not in the business world that Novell and al. are targetting, but surely in the other world. Including that run on platform (recycled) whose card vendor refuse to support (think nVidia on PowerPC), etc. There are plenty of reasons why 3D support should NOT be a requirement. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
I would like to propose LAT 1.2.x for inclusion in GNOME, specifically to the Admin Suite. What was meant to happen is now happening. Now that Mono has been blessed for note taking application, people try to push their own tools written for Mono into Gnome. My vote is NO. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Friday 08 September 2006 08:57, James Henstridge wrote: The real issue with handling development in parallel branches is really complexity of merging. This is an area where Subversion doesn't really buy you much over CVS -- you still need to manually keep track of what you merged to do a repeated merge. Yet another piece or urban legend. Obviously you have never used the command svnmerge (now part of the svn package). http://www.dellroad.org/svnmerge/index Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
getting on a longer release cycled
Hi, I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. There have been a large pimping of project Topaz, and I strongly believe that this is the kind of goal that would need a longer development cycle for a big leap forward towards world domination. Why not thinking for after 2.18 starting on a 12 to 18 month release cycle. We must have a FIRM date (eventually flexible), but more importantly a FIRM features goal (eventually adapted to not become a Death March). What do people think? Hub pgpA2mFft1ydu.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thursday 07 September 2006 14:51, Jamie McCracken wrote: I dont know how topaz will transpire but I feel it should be written in a native high level language like D or Vala as its likely to be a rewrite of much of the existing code and could be doable in 9 months with a more productive language. Did you drink the cool-aid? (I'm talking about using either D or Vala) Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: sticky-notes - tomboy conversion
On Tuesday 22 August 2006 13:53, Emmanuele Bassi wrote: Deprecating does not mean removing. Yeah, look at Bonobo and Orbit :-) I also asked[1] for a separated package for sticky-notes, in case distributions want to pick it up. What about a separate package for Tomboy so that one does not have to pull Mono to build the desktop? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Alex Graveley alex at beatniksoftware.com writes: * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. That was the subject of my talk at Desktop Developer Conference (this minor conference that was earlier this week like evey year since 2004), were I proposed ideas toward a *cross desktop* implementation of such a framework. The people from KDE I did talk too were there are higly interested in such a feature. DBus for this framework would just be an IPC mechanism, and not the object model. I'll post the slide sometime next week when I actually have time to do so, but I certainly want to push an idea like that to be implemented. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Jason D. Clinton me at jasonclinton.com writes: * Lots of cool applications and innovations are happening in the Mono camp. There's apps. like F-Spot, Tomboy, Beagle, and Banshee being written way faster than they could be in C. Anti-Mono folks generally agree but think that high level languages should only be used for prototyping (the benefits of RAD don't outweigh the cons). There also another solution that seems to be completely ignored each and everytime in the equation: what about C++. C++ would allow lot of things to be done easier than in C (look are how many lines of code you need to write to just create a new gobject? why is there gob again?). That would probably solve lot of issues people have with maintaining or writing C application for Gnome. For those who don't believe me, have a look at your friends of KDE. They produce a huge amount of application written in C++ with Qt and sometime it looks like Gnome is really lagging behind. Too bad for us, we have a very good C++ framework called Gtkmm (Thanks Murray and al. for this), even if it is not even required (Ekiga and AbiWord are good examples of C++ application using plain C APIs). On more advantage is that using C libraries comes for free. No need to write binding or wrapper or whatever to use them. And it is fairly easy to write C++ libraries that gets good C APIs Just to outline that managed language are not the only answer to C application are getting harder to maintain. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
Iain * wrote: Once again, who are we targetting with the desktop. Apple know who they're targetting, which is probably why text editor and terminal are not high on the list of features. I thought we were targeting a desktop platform for ISV to integrate it? In that case it make sense to provide modules. BTW what about providing the Office suite first? Because Gnome penetration is first into large business [1] deployment, and and Office suite is more likely to hit that target. We still don't, but distribution vendors do. Nobody install Gnome as is, but everybody install a distribution that comes with Gnome (or KDE). That is were things are, and distribution vendor are our first ISVs. Hub [1] business as in opposition to home market: cities, universities, whatever were people do *productive* work and not hobby/entertainment, which is essentially e-mail, web-based, office (word processing, spreadsheets), etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
Iain * iaingnome at gmail.com writes: Why do we feel we are able to bless a terminal program and a text editor and a clock, but unable to do the same to a video editor or an audio editor? There is a huge difference between essential programs (editor, terminal) and specific applications (photo management, music editor) And to return the example or Apple/MacOSX. iPhoto, Garage Band and iMovie are part of the iLife suite. It comes bundled with the machine like the OS. Not with the OS. If you pay the $149 upgrade fee for MacOS X, you don't get and upgrade of these. You have to pay another $79 to get it upgraded (actually there is no upgrade price). That clearly show that there are just different package bundled together with a machine. This is the distro choice. If we want to take care of all of this, why don't we just create Gnome Linux, and pick the kernel, the base system, the package management, etc. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
