[Goodies-commits] r1778 - xfce-menu/trunk

[Jannis Pohlmann]

Author: jannis
Date: 2006-07-21 12:41:31 +0000 (Fri, 21 Jul 2006)
New Revision: 1778

Added:
   xfce-menu/trunk/STATUS
Modified:
   xfce-menu/trunk/ChangeLog
Log:
	* STATUS: Detailled information about the implementation status added.

Modified: xfce-menu/trunk/ChangeLog
===================================================================
--- xfce-menu/trunk/ChangeLog	2006-07-21 11:23:12 UTC (rev 1777)
+++ xfce-menu/trunk/ChangeLog	2006-07-21 12:41:31 UTC (rev 1778)
@@ -1,5 +1,9 @@
-2006-07-21	Janins Pohlmann <jannis at xfce.org>
+2006-07-21	Jannis Pohlmann <jannis at xfce.org>
 
+	* STATUS: Detailled information about the implementation status added.
+
+2006-07-21	Jannis Pohlmann <jannis at xfce.org>
+
 	* libxfce4menu/xfce-menu.c: Destroy the menu parse info in
 	  xfce_menu_finalize, not directly after parsing the menu. Free
 	  old parse info directory name when the menu directory name has 

Added: xfce-menu/trunk/STATUS
===================================================================
--- xfce-menu/trunk/STATUS	                        (rev 0)
+++ xfce-menu/trunk/STATUS	2006-07-21 12:41:31 UTC (rev 1778)
@@ -0,0 +1,118 @@
+XDG menu specificatiom implementation status
+=======================================================================
+
+   I. Menu file elements
+  II. Filesystem monitoring
+ III. UI interaction
+
+
+
+I. Menu file elements
+=====================
+
+  [x] <Menu>                    
+
+  [x] <AppDir>                 
+
+  [x] <DefaultAppDirs>
+
+  [x] <DirectoryDir>
+
+  [x] <DefaultDirectoryDirs>
+
+  [-] <Name>
+        The <Name> is parsed and implemented as a property of XfceMenu
+        but there are no functions yet to parse menu paths, such as
+        "/Applications/Graphics".
+
+  [-] <Directory>
+        Currently, only the last <Directory> element to appear in the
+        menu file is checked. The spec says: 
+
+          "The last <Directory> element to appear in the menu file 
+           "wins" and other elements are ignored, unless the last 
+           element points to a nonexistent directory entry, in which 
+           case the previous element should be tried instead, and so 
+           on."
+  
+        So we need to use a list instead of just one string for
+        parse_info->directory_name.
+
+  [x] <OnlyUnallocated> and <NotOnlyUnallocated>
+  
+  [x] <Deleted> and <NotDeleted>
+
+  [ ] <Include> 
+
+  [ ] <Exclude>
+
+  [ ] <Filename>
+
+  [ ] <Category>
+
+  [ ] <All>
+
+  [ ] <And>
+
+  [ ] <Or>
+
+  [ ] <Not>
+
+  [ ] <MergeFile>
+
+  [ ] <MergeDir>
+
+  [ ] <DefaultMergeDirs>
+
+  [-] <LegacyDir>
+      
+        <LegacyDir> elements are parsed into a string list, but there is
+        no further parsing or merging performed afterwards - not yet.
+
+  [-] <DefaultLegacyDirs>
+    
+        See <LegacyDir>
+
+  [-] <KDELegacyDirs>
+
+        See <LegacyDir>
+
+  [ ] <Move>
+
+  [ ] <Old>
+
+  [ ] <New>
+
+  [ ] <Layout>
+
+  [ ] <DefaultLayout>
+
+  [ ] <Menuname>
+
+  [ ] <Separator>
+
+  [ ] <Merge>
+
+
+
+II. Filesystem monitoring
+=========================
+
+  With a proper GObject structure for all classes (XfceMenu, 
+  XfceMenuDirectory, XfceMenuItem etc.) reloading objects independently
+  of each other should be no problem.
+
+  The only question is how monitoring should be done. Perhaps we can 
+  copy parts of ThunarVFS for this (as using ThunarVFS would only be 
+  possible if Thunar wouldn't use libxfce4menu).
+
+  So, unless there is a better method, FAM/Gamin would be used for 
+  monitoring files and directories.
+
+
+
+III. UI interaction
+===================
+
+  Using GObject signals it should be easy to connect to menus and
+  menu items in order to update the related widgets.