home *** CD-ROM | disk | FTP | other *** search
/ PC Professionell 2005 June / PCpro_2005_06.ISO / files / opensource / inkscape / Inkscape-0.41-1.exe / doc / WISHLIST < prev   
Encoding:
Text File  |  2005-02-09  |  2.3 KB  |  67 lines

  1.  
  2. Sodipodi Wishlist
  3. -----------------
  4. This file is for capturing random details about desired development
  5. work, ideas, etc.  The Sodipodi feature request page is probably a
  6. better location for such things, but this can serve as a convenient
  7. scratchpad. 
  8.  
  9.  
  10. Rework xml tree
  11. ===============
  12. use reprs as lightweight wrappers around gnome-xml,
  13. keeping syntax as close to DOM as possible
  14.  
  15. -- Lauris
  16.  
  17. Split SPDesktop object into modular inherited objects
  18. =====================================================
  19. SPDesktop - base, has drawing group, no contexts
  20. SPEDesktop - editable desktop - more full-featured
  21. SPNamedDesktop - Desktop, deriving its layout from NamedView - i.e. guides,
  22.   grid etc. will be saved per-desktop
  23.  
  24. desktop_show_borders/hide_borders - show/hide rulers & stuff - usable for
  25.   Bonobo component
  26.  
  27. -- Lauris
  28.  
  29. Next rewrite of object-tree... Completed
  30. ========================================
  31. Ideas:
  32. Basic entity will be SPObject, which can well be non-graphical (undo list)
  33. nontrivial (grid) or conceptually different (namedview) object.
  34. But still they have to maintain object-repr relationships.
  35.  
  36. object methods:
  37. (destroy, set_arg)
  38.  
  39. void build (SPObject * object, SPDocument * document, SPRepr * repr)
  40. Reads full tree-definition from repr, building all children, if necessary
  41.  
  42. -- Lauris
  43.  
  44. Javascript for Animation support(?)
  45. ===================================
  46. > The mozilla javascript engine is under dual MPL/GPL
  47. > (http://lxr.mozilla.org/seamonkey/source/js/src/) and written in C. 
  48. > Hopefully there's some nice way to build off that...
  49.  
  50. The main reason JavaScript would be tricky is that it would be modifying
  51. the document out from under you via the DOM, so you couldn't have a
  52. "time slider" or something like you could for the SMIL stuff.
  53.  
  54. That's a real headache, and the only way I can see it working is if the
  55. document is cloned and played back in a separate "audition" window, then
  56. the modified document thrown away at the end.
  57.  
  58. But then, why implement Javascript in Sodipodi?  An audition feature
  59. that calls out to an external player application would work just as well
  60. (and indeed, that's exactly how applications like Flash cope with
  61. scripting).
  62.  
  63. [ note that implementing scripting for Sodipodi itself is a separate
  64. issue, and probably warrants a language-agnostic scripting interface
  65. like the GIMP's PDB, only less grotty ]
  66.  
  67. -- Mental