From: Milan B. <mi...@km...> - 2005-01-28 21:44:06
|
Nando Dessena wrote: > M> My idea is to split OptionsFrame in two parts. On the left side, we > M> would have a tree control with hierarchy of options (which can be read > M> from some .xml definition file). On the right side would be a array of > M> options in that node, placed in vertical order. This is setup similar to > M> Mozilla/Firefox preferences, Gnome options dialogs or Windows registry > M> (although windows registry is more primitive than this). > > I take it the tree would show an item per category and each category > would be made up of a number of settings. Am I right? > If so, do we really need a hierarchy of categories? I wouldn't want FR > have the wealth of options IBExpert has - that's scary and > overwhelming. Well, I don't know. Currently I don't see many options, but it can grow. I guess we can still use a tree with just one level of depth. That way we can expand it later if we wish. A good comparison would be Firefox and Mozilla. Mozilla has a tree and many, many options. Firefox has a left side bar (like MS Outlook) and only 5-6 items in it. It does look nice, but they are going to have problems if they want to give more options to user. So, I'm going to go for the tree, if anyone objects, this is a good time :) I'm bringing this back, since I plan to implement it soon. The engine of OptionsFrame itself can be built without any connection to DBH, or even any connection with FlameRobin. We can write the engine that simply reads the .xml definition file, and shows number of options to set. It's only interface to FlameRobin is the config class which does the actuall read/write/get/set stuff. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |