Re: [Flamerobin-devel] The next step

[Milan B. <mi...@km...>]

Nando Dessena wrote:
> M> Fine for initial loading. But later, user might "move" database from one
> M> folder to another, and it can get complicated.
> 
> Wouldn't just clearing the tree and rebuilding it be enough?

It would be enough, yes. But, do we really want to recreate entire tree for 
this? OTOH, looking at wxTreeCtrl, it seems that there are no functions to 
"move" part of hierarchy around, so it may be the only option.

> M> When you start with "empty" FlameRobin, how do you create the initial Folder?
> You create the initial database and call it 'Folder/Database'.

I find this a little awkward. It is fine when you explain, but I believe that 
the first-time user will get confused.

> M> how do you add new folders? Example: User has a database Employee
> M> in folder Test. He wants to  have new folder for it, called
> M> OldStuff. Now, how does he proceed?
> 
> He opens the database property page and changes 'Test/Employee' to
> 'OldStuff/Employee', then clicks Ok and the tree is rebuilt.

IMHO, it would be much intuitive if he could just create empty "OldStuff" 
folder and then simply drag&drop the database there.

> I know this has advantages, like the inability to sort folders in a
> custom way (but we alpha-sort servers and databases already).

Not neccessarily, we can add an int member to Folder class, which will be 
called "position" or something like that, and we can sort nodes by that. It 
would be saved together with other folder data.

> M> simply creating new empty folder is the most user-friendly and
> M> self-explanatory way.
> 
> Yes. But once the user learns to do it the other way, he might find it
> even easier. Well, at least until he wants to rename a folder. :-/

LOL :)

> All in all I've no strong opinion. I can see advantages and downsides
> to both approaches.

I still have a strong bias that we should be able to have "empty" folders. 
However, this does not apply that Folder class must be a YxMetadataItem 
descendant. We can have a separate hierarchy of Folder objects, and each of 
them can contain other folders and databases. Each Database object would be a 
top one in its own DBH.

--------------------------------------------
<idea>
         <type>crazy</type>
         <expected implementation>never</expected implementation>
         <description>

Later we could even add ability to symlink databases, so you can have 
something like:

DBbyFunction (folder)
- ERP (folder)
   - ERP-client1 (db)
   - ERP-client2
- Retail
   - Retail-client1
   - Retail-client2
   - etc.
DBbyClient (folder)
- Client1 (folder)
   - ERP-client1 (db)
   - Retail-client1
- Client2
   - ERP-client2
   - Retail-client2

So, database ERP-client1 is the same database linked in 2 different folders.
	</description>
</idea>

-- 
Milan Babuskov
http://fbexport.sourceforge.net
http://www.flamerobin.org