Re: [Demexp-dev] Organization of tags

[David MENTRE]

Hello Félix,

address@hidden writes:

> When using the client recently, and due to the growing number of tags, I've
> become
> a bit frustrated by their "flat list" organization. I took the liberty of
> writing
> my thoughts about a possible approach on the wiki, here:
> http://www.demexp.org/dokuwiki/doku.php?id=hierarchy_of_tags
>
> Let me know what you think.

Ok, several remarks:

 o Having a hierarchy of tags is a fundamental departure from our
   previous flat approach. I haven't anything against it but we need to
   recognize that this change is a fundamental one;

 o I put as a mandatory requirement that the hierarchy of tags is
   separate from any classification on the server. It should not
   influence the official server classification and be orthogonal to
   it. 

 o The general behaviour of the client loading separately the raw set of
   tags from the server and a hierarchy of tags from a specified
   location seems a good idea to me. The client is in charge of merging
   the two sets.

 o Regarding implementation, I see no fundamental issue, although this
   is not a trivial change:

   - in the client, the current TreeView used to list the tags is able
     to handle a tree with (un)folding operations. However, using a tree
     is going to impact the code listing questions in the middle panel
     and refreshing callbacks (after a question has been seen/voted). As
     this code is currently quite messy and buggy, this could be an
     opportunity to fix that;

   - we need to define a format for describing this hierarchy. I'm
     thinking at a simple XML format, that could be parsed and generated
     by other tools/languages;

   - the organizer application should be rather simple to code (a
     TreeView, four buttons up/down/left/right, two buttons load &
     save), even if not entirely trivial (lablgtk2 is not simple to
     use);

   - loading of the tag hierarchy file could be done using curl, which
     is already a dependency of demexp through cduce.

So, I short, I agree with your proposal. On the implementation side, it
should be doable, albeit not a trivial change.


Yours,
d.
-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A