Warning: session_start(): open(/tmp/sess_9q01d6stldlqvs8rlddu4gpc13, O_RDWR) failed: No space left on device (28) in /www/H01/htdocs/lib/base/lib_base.php on line 280
Poll openDesktop.org
-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   
 
Home
Apps
Artwork
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login

-
- Poll . 

A central repository for KDE configuration data?


Posted by Yaba on Jan 2 2005
YabaYaba
editor
Home
Using Elektra would be great (elektra.sf.net)37%37%37% 37%
A new registry database like implementation3%3%3% 3%
All config data should be in a fast database9%9%9% 9%
One central XML file.7%7%7% 7%
A new, but tighter organization of text files.10%10%10% 10%
Various text files are good enough.3%3%3% 3%
The current implementation below ~/.kde is best.32%32%32% 32%
Votes: 1173
goto page:  1  2  3 

-

 no registry please!

 
 by blaster999 on: Jan 3 2005  
Score 50%
blaster999blaster999
Aisys
Home

Don't create anything registry-like. If you've used M$ Windows, you know that its registry is a pain in the ass (like everything else in windows). Plain text config files or XML would be good enough for config files.

It is not the size of the hammer that counts. It's how you wield it.
Reply to this

-
.

 Re: no registry plea

 
 by gg3po on: Jan 3 2005  
Score 50%
gg3pogg3po

I agree! Please don't use a registry! This is why I don't like Gnome, anymore.

-3po
Reply to this

-
.

 Re: Re: no registry plea

 
 by leinir on: Jan 3 2005  
Score 50%
leinirleinir
KDE/Amarok, KDE/Gluon
editor
Home

As far as I know, GConf isn's a registry, in that it's not a binary database... Please, do correct me if I'm wrong, but I seem to remember that being discussed before.

..Dan // Leinir
http://www.leinir.dk/
Reply to this

-
.

 Re: Re: Re: no regis

 
 by gg3po on: Jan 8 2005  
Score 50%
gg3pogg3po

I'm sure you're correct here, but maybe it just feels too much like the Win registry too me... I'm maybe not qualified to opine here, since I only saw the first iteration of Gconf a while ago, when it first came out. I know this is a subjective thing...

I really didn't feel that Gconf was very user-friendly -- not that text files are, either, but I don't see the advantage... I would like to see, perhaps, some kind of GUI frontend to the config files, but It should use standard widgets, logically organized in a way that's specific to each problem. eg: tabs, radio buttons, etc. and not try to *look* like a registry (which tends to look like a database frontend with cryptic names for everything [I know. Text files are cryptic, too, but isn't a GUI supposed to elimate this?]).

I'm really not trying to criticise. I hope I don't sound that way.

-3po
Reply to this

-
.

 Elektra

 
 by smileaf on: Jan 4 2005  
Score 50%
smileafsmileaf
Home

Correct me if I'm wrong but it looks like this is just a project that wants to expand the ability of configuration projects in that it does NOT really centralize the data. but rather centralizes how data is accessed.
If this is the case then Yes I like this idea! .. I agree that figuring out all those different file structures is a pain. some are down right unreadable IMO.

I personally don't think the windows registry is that bad of an idea. easy to access(I would assume) and browsing it in regedit gives everything the same config layout (yes it is a nightmare to browse tho..)

if Elektra is nothing but a way of accessing these config files then there is no "oops I lost the registry now I have to reinstall" like you have in windows.

but then at the same time if elektra is like that.. doesn't KDE already have a consistent config file structure?

this comment has been leafed...
Reply to this

-

 Re: Elektra

 
 by reignbow on: Jan 4 2005  
Score 50%
reignbowreignbow

The Windows registry may not be a bad idea in theory (some disagree), but it certainly is a pain the way it is implemented. Commonplace problems are insufficient access restriction, the inability to determine which program owns which keys, unclean deinstallation, and deterioration of system performance as the registry fills up. Elektra seems to avoid most of these by its clear layout, emphasis on access control and bare-bone implementation. I'd like to see Elektra be given a chance. Maybe someone could run some trials on how it fares in bootup and system operation?


Reply to this

-
.

 by now it's good

 
 by ra1n on: Jan 5 2005  
Score 50%
ra1nra1n

I voted for a new, but tighter organization of text files.
The reason is simple, those files should not be accessed by the normal user, he should use the gui config dialogs.
Those files should be accessed only for particular reason (for example for tweaking some particular option) and in this case they should be clear and maybe well documented.
Also they should be easy to restore if something goes wrong, and there is nothing more simple to handle than a text file
So there should be a new layout for configuration files, but they should remain text files (or at least XML files)


Reply to this

-
.

 Ummm Y?

 
 by nightwriter on: Jan 5 2005  
Score 50%
nightwriternightwriter
Home

It works. It works very well. Every user who needs to, knows how it works. All of the tools are designed around what exists. Fantastic progress in speed and quality are being made in the product as a whole.

Sounds like the perfect time to dump it all confuse the heck out of every one and change the entire methodology of configuring the product. I mean, I'm sure the distro's would love a reason to rewrite all of their tool integration as well, they must be bored as heck (Cheesy grin and sarcasm applied)

If however there is a real problem, as in a roadblock, a no can do or never will be able to, perhaps. But nothing I've seen especially since 3.0 came out (3.3 rocks and 3.4 will hopefully soon be built by me *grin*) Why sidetrack this role by throwing out the baby and keeping the bathwater?


Reply to this

-

 keep in FS

 
 by mirya on: Jan 5 2005  
Score 50%
miryamirya
ua.pmmci.com
Home

IMO the only reason to create the registry is filesystem design aimed toward large files support, not couple-of-bytes entries, which often means resource waste and great slowdown (as it was with FAT).


That would be nice to have a registry-oriented filesystem (mean real UNIX FS) for that. And btw, the registry problem exists in Wine projects for years, they work with one-large-regedit-export format for now, that really eats resources as the only operations on such "registry" is load-all-at-one and save-all-at-once.


Like this:
$ mount
...
/usr/local/share/kde/registry.kreg on /usr/local/registry/kde (regfs, local)

Best regards, Mirya
Reply to this

-
.

 current is the BEST

 
 by Zlodej on: Jan 5 2005  
Score 50%
ZlodejZlodej
SAK

KDE works fine for me for now, switches between 2 sessions for 1,5 sec.
Who likes faster system can buy 64-bit Intel CPU and RAID.


Reply to this

goto page:  1  2  3 

Add commentAdd commentall pollsSuggest new pollBack



-
Linux42.org
-

Popular Groups
-

Newest Groups
-

FORUM
-

 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Artwork
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Content RSS   
Events RSS   

Participate
Groups
Forum
Add Content
Public API
About openDesktop.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2007-2016 openDesktop.org Team  
All rights reserved. openDesktop.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
openDesktop is a trademark of the openDesktop.org Team