From: Eero T. <eer...@ne...> - 2005-03-01 21:49:04
|
Hi, (This is getting a bit off-topic. Others, please yell if this starts to bore you, so that can we move this to a private discussion. :)) > > > and many various *nix systems run Qt/Embedded if they lack the space > > > for a full X server. > > > > Qt/Embedded is just a GUI toolkit, it's not a desktop environment. > > And all this discussion is about is allowing the user to change the GUI > toolkit used. > > > It lacks several of the features required by Gramps (for example a > > mime-registry for running automatically viewers for the reports which > > is pretty convenient). > > So then that feature wouldn't be available under Qt/Embedded systems > unless someone cared to add Opie support to GRAMPS. I've never seen > GRAMPS do this (or even have the need to do it), so it can't be that > important of a feature-- as you said, just convenience. The point I'm trying to make is that there's also quite a lot of functionality in Gramps that doesn't come from the Gtk, but from Gnome. The project that does a port of Gramps to a different toolkit and ignores the rest of the convenience stuff (at least until all of the basic UI is working in the new toolkit) is Gramps-tk. > > Qtopia again is not Open Source, unlike Gnome or KDE. > > GPL isn't considered Open Source now? > "The freely downloadable version of Qtopia is provided with no support > and no warranty. It is provided under the GNU General Public License, > GPL." - http://www.trolltech.com/download/qtopia/index.html?cid=22 Hm. I had thought there was something that OpenEmbedded distro needed to replace to get Open Source code stack out of TrollTech palmtop environment, but seems I was wrong (or it has changed at some point)... Sorry! > > Some people use *console* applications, but nobody uses framebuffer > > applications. What would be the point? > > I'm sure plenty of people do... I doubt all those console-only people > browse the web in text: links -g makes very good use of the fb It's a cool hack (as is the support for graphics in Xterm), but if you can already use graphics (you have a local session), why to limit it to what framebuffer offers? Nobody uses that for serious work except occasional hacker, and I doubt even they would do it regularly. If you're not using it regularly, where's the incentive to maintain it in the long term? I mean, do you see yourself doing a port of Gramps to framebuffer and maintaining it for the next 5 years? (I'm "maintaining" a program for GGI, SDL, linux framebuffer, DOS, Amiga and Atari, but it's a game, not a serious application... :)) > > > > Occasionally, someone wants us to change our direction. These have > > > > included requests to rewrite in C++ (because python isn't a real > > > > language), > > > > > > There isn't some rule saying that a project can only have one > > > official version. For example, back years ago I have a project called > > > ODC. There was a Visual Basic version and a Java version, led by > > > different people only really similar because of their design. > > > > > > > rewrite in php and become a web application, > > > > > > Now that would be an interesting extension... though I'm pretty sure > > > it would work just fine using Python. > > > > There are already exising the www/php/mysql based genealogy programs. > > None that I have seen comparable to GRAMPS. UI wise or functionality wise? > > Www-application interfaces suck when compared to real applications > > Web applications are just as much real apps as any other is and in many > cases, more usable because Joe User X doesn't need to install anything. I was referring to the user interface and it's usability. > > that integrate to the desktop. > > If desktop integration were this important, that alone would be reason to > support Qt/KDE since it is the primary *nix desktop environment. Well, Linux has two main desktop environments, Gnome and KDE. Major distros support both and it depends on distribution which is *its* primary desktop selection. My desktop at Home is KDE, at work it's Gnome (and it's been like that for several years). Gramps project has picked Gnome. > > > > So, in summary, the project is going in a direction that seems to > > > > meet the needs of our users. If we changed directions, we might or > > > > might not be able to reach a larger audience, but numbers are not > > > > our goal. We fully support others submitting patches and other > > > > contributions, but they will be weighed on how they match the goals > > > > of the project (and most of the patches we've received to date do > > > > match the goals). If someone wants us take the project in a > > > > different direction, we may or may not be receptive depending if > > > > the direction matches our goals. However, we will support your > > > > efforts if you decide to fork the project. Who knows, maybe a > > > > remerge will occur in the future, or a forked project will make us > > > > irrelevent. > > > > > > The problem with merging separate projects is that you lose the CVS > > > history of one of them. If both 'projects' were instead branches in > > > CVS (one being an unsupported branch, even), they can be easily > > > merged any time. > > > > Hm. Are you really saying that we should change from CVS into using a > > distributed version control system so that everybody could maintain > > his/her own branch without disturbing the main project? > > No, I was saying that the GRAMPS project can open their CVS repo to more > than just official branches. I'm not sure what means an "official branch". Branches can be done by anybody having access to CVS, so it's just a question of who maintains the branch. In Open Source projects you get CVS access after you've provided enough useful patches or other stuff to the project i.e. demonstrate reasonable amount of commitment to the project and its goals. Because support for other toolkits is not in the Gramps goals (there's too much missing functionality to have time for that) I would think it would be easier to start experimenting with the toolkit stuff with the Gramps-tk project as they've investigated the issues a bit more. Maybe it will at later date merge with Gramps. Some changes from Douglas have already been merged to Gramps (e.g. having an alternative backend for storing preferences into Gconf). > However, changing to a distributed VCS would also work. > > > AFAIK this works pretty well in the case of the Linux kernel project. > > However, changing version control system is a major undertaking... > > Too bad GNU Arch's cscvs doesn't work yet... then it would be possible to > convert CVS to Arch easily. Does Sourceforge support anything besides CVS? - Eero |