From: Maia K. <si...@ub...> - 2009-12-17 13:56:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 libglade and gnome-vfs are deprecated, and will be removed entirely in GNOME 3. Two years ago, we raised the minimum GTK dependency from 2.6 to 2.8 (for cairo, replacing gnomecanvas in drawing cover art). Perhaps now, it is time to raise it once again, to 2.12? GTK 2.12 was released back in September 2007 - long enough to get adopted by all modern distributions. Also, gnome-vfs is deprecated in favor of gio, in Glib since version 2.15 (our dependency is 2.8). Should gtkpod be ported to gio too? Ideally, we should clean up the libhal dependency as HAL is now also being deprecated, but that can wait. What do you think? Is porting from deprecated functionality to its new, supported replacements worth bumping Glib and GTK dependencies? (While we're at it, maybe we could also consider migrating from GNU autohell to a less stone-age build system? For example, cmake? That is more a matter of preference, though, but it may begin the process of porting gtkpod to other systems without the need for cygwin.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLKjKtAAoJEDqDNnQ69yYSKecH/i6ezsLG96aQdjT3YTeWKtTp GfcUjGcHaRJSzlM4tCEh4833UYZdBIkS6pTN+9hEvxaveDFd/oD6nqalEGLST2X/ Pu32qtfC47b/ggs4HhLtL+PkrUnBFsxnXY9clGx3/fwCLTaUa0VdIxALdm5MyuD0 gzFg3JhjEWQ/d8ohqh3sS/GvG2iqAMkIZ09NgCw17N0uK+joaEsJi9wC5c15LNa1 aoZdLzY2AM7ezbh0slQw4V+XThs29ghSByahZG+tG1jrruCjgF3DuulgR8LimQkh ne9kRR0Gfzo+VESeCpkalXKcDBnxX7FWF03u9IWgzBYUfkklR/x6tl8RfECVMy4= =lk4b -----END PGP SIGNATURE----- |
From: Maia K. <si...@ub...> - 2009-12-18 11:38:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 18.12.2009 17:35, P.G. Richardson wrote: > These sound like sensible suggestions. > > Given that the library dependencies are going through big changes anyway > due to porting gtkpod to the anjuta framework, this would certainly be the > right time to do it. > > If anyone feels like enacting these changes then please go ahead and > commit to the master branch. Shall port the changes over to the > plugin-framework branch when complete. > > Certainly, gets my vote to update from autogen. > > Regards > > PGR Anjuta framework? What did I miss? :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLK2mcAAoJEDqDNnQ69yYSCYkH+gJx4b/Xjk0ZHV9ok+ZbIkEo Ih4RnQrCNNxRS/ge9uV48kwd98cS8eFf5sBhLaC/X8EYun76I9QwNGPPlDQZ9nx8 ljeKHWi2kwbVgFsFX5u46WwMTClNwdq2MN6gsUqPxOSi7CdY3IPGWtWYK+fBs/5x NYrxfN94ICqO6hU1vQXKzL1iQzduGABEe4XiN4oVmn9XZGmqOxsRHl2jrzRIZUTX iejrtHwZ+iASride/o3YIchs6Fe1SHo3sjGL+gsDoXfQKJoUg8etABiFcOT+Zeq+ oPQBMjZuKAEfkteAFu3LpapJAryjqM/AifsrIvjNIhSlZsls6mJUOUhkHqhIovM= =aMDs -----END PGP SIGNATURE----- |
From: P.G. R. <p.g...@ph...> - 2009-12-18 12:39:05
|
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 18.12.2009 17:35, P.G. Richardson wrote: >> These sound like sensible suggestions. >> >> Given that the library dependencies are going through big changes anyway >> due to porting gtkpod to the anjuta framework, this would certainly be >> the >> right time to do it. >> >> If anyone feels like enacting these changes then please go ahead and >> commit to the master branch. Shall port the changes over to the >> plugin-framework branch when complete. >> >> Certainly, gets my vote to update from autogen. >> >> Regards >> >> PGR > > Anjuta framework? What did I miss? :) :-) Well, I started a few months ago on coverting the UI of gtkpod to the anjuta framework. This affords several advantages: - gtkpod components can be moved around in the UI to suit a user's preference; - new plugins can be developed to extend gtkpod in a semi-independant fashion; - the non-UI parts have been moved into their own library - libgtkpod and all UI elements interact with that rather than libgpod and all the other libs - cause to review most of the codebase and determine what all the bits do and whether they are necessary, in the right location etc ... The plugin-framework branch is available from here -> http://gitorious.org/~phantomjinx/gtkpod/phantomjinx-gtkpod-plugin Have a look if you wanna understand what I am trying to do. Cheers PGR |
From: Maia K. <si...@ub...> - 2009-12-18 12:52:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 18.12.2009 18:38, P.G. Richardson wrote: > The plugin-framework branch is available from here -> > http://gitorious.org/~phantomjinx/gtkpod/phantomjinx-gtkpod-plugin > > Have a look if you wanna understand what I am trying to do. > > Cheers > > PGR Unfortunately, when I tried to checkout the plugin-framework branch, it turned out half the files in libgtkpod are symlinks to files in /home/phantomjinx. Can it be fixed? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLK3sOAAoJEDqDNnQ69yYSTtgH/jfzkeOoJ+yc4ZMtzktjkjQU KNueekQ5oFiBhKzgU0NGNOtliDMGqKjQPaXSFMKbNI/rTwhfiORyx2BPyaB4bTGM PYDfB0jHLZHcAOfrkbmLqKDj0TXl6VYtzHpLPgW+emuPKy11rP+5dT+TOcFMX3pF QcRp6muriXCjtezR3i/D930SZrmQ8IRVKFHkj/Xs20+er5VIh54l89Xkx4vs9qYT agCBFriIHCtmuYbr4BmbYwrwSqobkoOuhthWIFzeQ38lh3xW48GZQRMJIrV5/u4v 41aA77AIQWMitzTUkryQ0qNw2pFdMeevCpq2H7OZL8ynRE+2Z2RAepDR84pS7tk= =+jYq -----END PGP SIGNATURE----- |
From: P.G. R. <p.g...@ph...> - 2009-12-18 13:02:28
|
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 18.12.2009 18:38, P.G. Richardson wrote: >> The plugin-framework branch is available from here -> >> http://gitorious.org/~phantomjinx/gtkpod/phantomjinx-gtkpod-plugin >> >> Have a look if you wanna understand what I am trying to do. >> >> Cheers >> >> PGR > > Unfortunately, when I tried to checkout the plugin-framework branch, it > turned out half the files in libgtkpod are symlinks to files in > /home/phantomjinx. Can it be fixed? Certainly, doing it now. Thats what you get for coding at 10 o'clock at night ;) PGR |
From: P.G. R. <p.g...@ph...> - 2009-12-18 13:15:42
|
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 18.12.2009 18:38, P.G. Richardson wrote: >> The plugin-framework branch is available from here -> >> http://gitorious.org/~phantomjinx/gtkpod/phantomjinx-gtkpod-plugin >> >> Have a look if you wanna understand what I am trying to do. >> >> Cheers >> >> PGR > > Unfortunately, when I tried to checkout the plugin-framework branch, it > turned out half the files in libgtkpod are symlinks to files in > /home/phantomjinx. Can it be fixed? Done. |
From: Maia K. <si...@ub...> - 2009-12-21 13:59:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have committed a CMake-based build system to master. It is supposed to be a full replacement for the current automake-based system, including support for optional build dependencies. It would be nice if someone other than me could test it. Also, I have split data/gtkpod.glade into multiple .ui files for future use in GtkBuilder. Since most libglade calls are abstracted away and the two libraries are conceptually similar, migration shouldn't be hard - the only gotcha is that libglade supports the "root" parameter when creating the XML object and GtkBuilder doesn't, which is why we have to split the file. The ui files are not yet used for anything. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLL38mAAoJEDqDNnQ69yYSJXsIAI0f2wPDnv5o5Rse3o3KLY+A DtaQxcD61aDJ8hJTmZkbHjAVO2vfS6wPMyJWrs2giaGUecYs15swqs9A7BnlonrV swn5Efgm4SKXn5Q0eHO0N0s2KyG0GzJhlIR+nADEMuj6zAzgn40t5/EGezhYbEY5 OY5FZRkeusrYa9G937jFn3/VDjobGlekKs5hB3InmcNLUg/XqhRRy8qFpxl6v58W r+rKtPGoritzxLQbxH5XAH6HpFDgEYLLeKm2UV9tTE81Ckk/Ag62/KA6XnuJ2eSF qtOvvuuPhDhuOHnGfBiUqb205hRrubB5C6BwwTJgwnv8GTv/syhGRrZpcueZLhY= =Aua+ -----END PGP SIGNATURE----- |
From: Todd Z. <tm...@po...> - 2009-12-21 14:25:54
|
Maia Kozheva wrote: > I have committed a CMake-based build system to master. It is > supposed to be a full replacement for the current automake-based > system, including support for optional build dependencies. It would > be nice if someone other than me could test it. What exactly does cmake give us that we don't have now (aside from some ability to build for Windows, which I personally don't care at all about). I think we should take advantage of git and put these changes in a private repo while they're being developed and considered. At the least, patches to the list for others to look over, test, and discuss is probably a good thing. > Also, I have split data/gtkpod.glade into multiple .ui files for > future use in GtkBuilder. Since most libglade calls are abstracted > away and the two libraries are conceptually similar, migration > shouldn't be hard - the only gotcha is that libglade supports the > "root" parameter when creating the XML object and GtkBuilder > doesn't, which is why we have to split the file. The ui files are > not yet used for anything. I didn't these committed yet, but should we be making sweeping changes like this on master just yet? It seems like we ought to polish things up for a release before too long? Otherwise, gtkpod stays in a perpetual state of "almost 1.0." :) As far as bumping gtk+ requirement, I do note that Red Hat EL / CentOS 5 still ship with gtk+ 2.10. That's not a large target, but it is something at least a few folks have asked about in the past. I'm not sure it's worth supporting though. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There, I've gone and soiled myself, are you happy now?! -- Stewie Griffin |
From: Maia K. <si...@ub...> - 2009-12-22 13:28:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 22.12.2009 19:14, Christophe Fergeau wrote: > autotools-based projects also supports out-of-source builds. And you don't > need to rewrite your own make distcheck, make clean, .... and there are > nearly standard macros to check for modules using pkgconfig, ... make clean and pkgconfig are supported out of the box, and the very first Google result for "cmake distcheck" solved the distcheck issue too. (I should say this was the first time I even learned of such a command.) Note, however, that things like this are inherently bound to makefiles. I'm fine with libgpod remaining on autotools, since I neither contribute to it nor maintain it in Ubuntu. As for gtkpod... the code is there, the decision whether to use it is up to the other developers. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLMMlrAAoJEDqDNnQ69yYS+vsH/i6o9/O00pAaKoothmcnRvgb lw0w2YteDXTyXitfhMAASJBpJHolynI6ik8MKhIQY/iReI5qwAufOCpyYUeRPLv/ qjPHfw5U5RYVCxHrGJfU7kJCl8lItGlxzGG6hLgepFxaX2jb6GPNdU793/eLK1Hp vqrGMzJH0qRfAnHJLbeNk1qklUUS1z+fq5juZCuksw1sn+RF+qNf8JO7tq4Rl6Hs gTJluPcinj9/Uy04tok7DwH7K2ubZaJoUBry60gTIn147kAUzdbH49XsewVdhQ9f guAG1EquWP+BN2GjLCQlUDO+NFye5nrDKxbV/G1FSarEdwNjioeriAPi91mCs90= =8F+6 -----END PGP SIGNATURE----- |
From: Christophe F. <te...@gn...> - 2009-12-22 13:14:57
|
---------- Forwarded message ---------- From: Christophe Fergeau <te...@gn...> Date: 2009/12/22 Subject: Re: [Gtkpod-devel] Removing deprecated dependencies: libglade and gnome-vfs To: Maia Kozheva <si...@ub...> Hi Maia, 2009/12/22 Maia Kozheva <si...@ub...> What about the gnome-vfs transition? This will be less straightforward > since gio is not a nearly-drop-in replacement in the way GtkBuilder is > for libglade, but at least gnome-vfs is only used in one file and only > for automounting. Also, gio is a cross-platform abstraction for file > systems, so in the future it will enable us to replace platform-specific > stuff like unistd.h too. > Yep, would be good to switch go gio for volume monitoring. > - - cmake is well-documented and easily extensible. > - - Arguably more concise, intuitive and easy to learn. This is > > subjective, but compare the new CMakeLists.txt for gtkpod with its own > configure.in and tell me which one you consider more concise and > intuitive. > Fwiw I disagree with both of those ;) > - - Supports out-of-source builds. Cleaning up is as simple as deleting > the build directory. > autotools-based projects also supports out-of-source builds. And you don't need to rewrite your own make distcheck, make clean, .... and there are nearly standard macros to check for modules using pkgconfig, ... In short, I've been a bit disappointed by cmake, great promises, but really lacking in some area. But I'm not doing any work on gtkpod, so it's up to the gtkpod hackers to make a decision. Just for the record, I'm strongly opposed to switching libgpod to cmake :) > > Right now, though, the old autotools build system remains in place. The > cmake build is separate, and resides entirely in CMakeLists.txt and the > cmake/ directory. It was also an opportunity to clean up the cmake > version of config.h, and remove defines not actually used by the source files. Just saying. > One of the 2 build systems will probably end up lacking behind the other, so having both is not a long term solution. Anyway, these are just my 2 cents, thanks a lot for all the work you've done so far for gtkpod :) Christophe |