Error: no such theme PatternSkinTheme

Difference: InkTimeline (1 vs. 7)

Revision 7
2011-07-20 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
-- KateIngersoll - 2011-07-08
Line: 10 to 10
 
      • got Media-Scheme onto computer in Glimmer lab.
      • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.
    • Researching background info:
Changed:
<
<
      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might also be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.
>
>
      • Searched for articles that related to our project. To be honest, we didn't find very must that was useful, other than the MIT paper. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might also be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.
 
      • Learning about Inkscape, by reading about it, and messing around with it. (Kate) read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application.
      • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images).
    • Inventory: Started to make a list of what commands we wanted to implement.
    • Documenting: Gave a presentation on SVG to the glimmer team.
    • Links:
Deleted:
<
<
      • Daily notes from this week:
 
      • Our initial notes about Inkscape -InkCapabilities
Changed:
<
<
>
>
      • Our initial ideas for functions to implement- InkProcedures
      • MIT paper, useful sites for learning about SVG- InkArticles
 

  • Week Two:
    • Installing things/setup: Gave up trying to install Ubuntu 10.5 on glimmer computer.
Line: 34 to 31
 
      • Set up a Word Press Account- Sam wants us to blog weekly on our project.
      • Installed dbus on Glimmer computer.
    • Researching background info:
Changed:
<
<
      • In contact w/ Soren, (who worked on the 207 Glimmer/Inkscape project). Soren says that since then, he's created an Inkscape service for dbus. So, now our goal is to create our functions by calling the dbus methods Soren's already written (and maybe down the line, writing methods of our own.)
>
>
      • In contact w/ Soren, (who worked on the 2007 Glimmer/Inkscape project). Soren says that since then, he's created an Inkscape service for dbus. So, now our goal is to create our functions by calling the dbus methods Soren's already written (and maybe down the line, writing methods of our own.)
 
      • Therefore, reading up on what dbus is and how it works.
    • Inventory: continued working on an inventory of commands we'd like to implement. Note that this initial inventory was not really used later in the project (except maybe to help brainstorm ideas) as we had to work off of the functions Soren had already provided.
    • Links:
Line: 86 to 83
 
  • Week Eight:
    • Installing things/setup: Our goal for the last three week of the summer is to create a package of all of our work, so that people could easily download and use our console. To this end, Kim is working on installing the programs a person would need on a clean Ubuntu OS, so we can make a list of all the dependencies, etc and make a lovely Makefile.
    • Links:
Deleted:
<
<

Ink Script- For the Future

The annoying task of fixing things we've done

  1. Testing/Error messages: Currently, inkscript functions have minimal parameter checking. console.c includes type checking for the functions converted from dbus methods, so Media Script will print a useful error to the user if, for example, image-draw-polygon! is called with a string or a double value for "sides", but won't check to make sure that "sides" is only called with an integer larger than 2. There is no parameter checking in the wrapped procedures (found in wrapper_library.scm). It would help users if someone were to add parameter checking for all of the inkscript functions, using inkscript-documentation as a guide for valid parameter values.
  2. Improving methods: There are some methods that we're currently using that need to be wrapped with other functions in order to work correctly. It would be nice to re-write these methods, so the methods just do what we want in the first place.
    1. inkscape_draw_line (image-draw-line-orig!): same problem as inkscape_spiral. Wrapped func: image-draw-line!
    2. inkscape_load (document-load-orig): This method doesn't return a document-id number for the loaded document. A few notes: according to the documentation, this function should load a new image in the place of a given doc. In practice, this function only loads in the place of a doc if that doc is new. Otherwise, the image is loaded in a new window, leaving the given doc open. In our wrapped function, image-load! the image is loaded in a new window, but the function returns a doc-id.
    3. inkscape_move (object-move-orig!): This method only works if the object is already selected. Wrapped func: object-move!
    4. inkscape_move_to (object-move-to-orig!): same problem as inkscape_move. Wrapped_func: object-move-to!
    5. inkscape_selection_paste (selection-paste-orig!): This method doesn't paste the selection to any particular location of the document. The wrapped function isn't ideal, either: it just sends the pasted selection to the origin. Wrapped func: selection-paste!
    6. inkscape_selection_group (selection-group-orig!): This method doesn't return anything, but we want it to return the object id of the group. Wrapped func: selection-group!
    7. inkscape_spiral (image-draw-spiral-orig!): The spiral is drawn in the document's stroke color. If the document's stroke color is "none", the spiral's stroke should default to black. But instead, if the document's stroke isn't set, the spiral just isn't drawn. Wrapped func: image-draw-spiral!
  3. Improving wrapped functions: skewX, skewY, and scale.

Adding more functions!
  1. Current dbus methods: You may be interested in adding the rest of Soren's dbus methods. We implemented what we considered the most basic/essential inkscape methods, but if inkscript is getting expanded, it might be useful to include layer functions, update functions, the "image" function for importing a jpg image, etc. Once you have the source code for inkscape, and the dbus extension for inkscape, you should be able to find documentation for all of these dbus methods by running inkscape/src/extension/dbus/builddocs.sh. This will build the documentation from xml. If this no longer works (if you're running a newer version of the dbus extension, and this has changed) try looking for a notes or a readme file in inkscape/src/extension/dbus for instructions.
    1. unused methods: these are the methods that we decided not to implement. We haven't tested them yet.
      1. layer_change_level
      2. layer_get_all
      3. layer_new
      4. layer_next
      5. layer_previous
      6. layer_set
      7. select_all_in_layers
      8. move_to_layer
      9. selection_move_to_layer
      10. pause_updates
      11. resume_updates
      12. update
      13. get_path
      14. image
      15. mark_as_unmodified
      16. merge_css
      17. node => creates a node.
      18. selection_to_path
    2. broken methods: these are methods that we wanted to use, but they're broken, and need to be rewritten (as of 7/13/2011)
      1. close => causes Inkscape to crash
      2. exit => causes Inkscape to crash
      3. object_to_path => causes Inkscape to crash
      4. get_node_coordinates => causes Inkscape to crash
      5. star =>can't change # sides, or change the orientation, ('arg1', 'arg2', and 'sides' parameters don't change the final shape)
      6. selection_box => just returns an error message....
      7. undo/redo seem to work in some situations and not others.
      8. selection_get_center => error "no (de)marshaller for GArray type"
  2. Ideas for wrapped functions:
    1. object-set-style! and document-set-style!: There are about 101 different wrapped functions you can write with object-set-style! You can set the pattern of the stroke (solid or a type of dash, and the spacing of the dash), the style of the corners, and so on. We only wrapped the most basic of these (setting the color, opacity, and the stroke width). To figure out what style attributes you can set, I would suggest experimenting by hand with many different objects, and then looking at each object's xml. Note that the type of style attributes in "style" depends on the type of object. For example, for text objects, the "style" attribute is used to set attributes like "font-size", "font-weight", and "line-height", as well as the more standard "fill", "fill-opacity", etc.
    2. object-set-attribute! and document-set-attribute!: Likewise, there maybe be some wrapped functions you can write using the set_attribute command. Our notes for inkscape object attributes can be found in InkInkscapeNotes. These notes include all the major attributes for rectangles, ellipses, polygons, and text, but not necessarily all attributes for these objects. Once functions are written to draw stars, calligraphic lines, paths, etc, object-set-attribute! will be a very helpful function for writing object commands for these objects.
    3. image-call-verb!: Look into useful/interesting inkscape verbs you could call with image-call-verb!
    4. object-flip!: a function we meant to write, but ran our of time to wrap. Can basically be done with translation and scaling, but figuring out the values to translate/scale by could take a little time to work out.
  3. Ideas for new inkscape methods (i.e. methods you would have to write yourself for dbus):
    1. New tools: Not a comprehensive list, but some of the major tools for inkscape that we are currently missing.
      1. measure tool (just a proc to calculate the distance between two points)
      2. draw box
      3. draw paths/curves
      4. draw with calligraphic brush
      5. spraycan
      6. erase
      7. fill area
      8. color picker
    2. Setting contexts: we're wondering if it would be valuable to write a series of functions that define the context for each tool. For example, calligraphic-brush-context commands to set the type of brush ("wiggly', 'dip pen', 'marker', etc), the width, brush affects like 'thinning', 'angle', etc. In other words, a series of commands that correspond to the toolbar for each tool. For lines and brush-strokes, for example, it seems to make more sense to set the context then set the style of the brush each time you use it, since the user is likely to draw more than one line at a time, and it would be punishing to set the type of brush, the width of the brush, etc, for each individual line. Does it make sense to follow the model of setting-the-context for all objects? Would it be confusing for users to have a set of "context" commands for creating objects, and a set of "object" commands for modifying existing objects?
    3. ellipse-types: setting an ellipse to a segment or an arc. If the ellipse is an arc, it has the attribute 'sodipodi:open' and the value 'true'. So, to get the ellipse to an arc, one can use (object-set-attribute! doc ellipse "sodipodi:open" "true"). But, to set the ellipse to a segment from an arc, one can't just set sopdipodi:open to "false"; one needs to delete the sodipodi:open attribute itself. Currently, we don't have a way to delete attributes.
    4. filters: a series of commands to apply filters, gradients, and patterns. A series of commands to list valid filters, gradients, and patterns. Note that filters, gradients, patterns, etc are assigned urls. So, if an object is filtered, the 'style' attribute of the object will include a 'filter' attribute such as "filter:url(#filter3425)". BUT, the url of a filter changes in each instance of inkscape! So, in one image, #filter3425 might reference the "cubes" filter, and in another image, it might reference the "felt" filter. urls are defined in the xml for a document under . That's about all we know; more experimentation/research needed.
Revision 6
2011-07-14 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
-- KateIngersoll - 2011-07-08
Line: 81 to 90
  Ink Script- For the Future

The annoying task of fixing things we've done
Deleted:
<
<
  1. Testing/Error messages: Currently, inkscript functions have minimal parameter checking. console.c includes type checking for the functions converted from dbus methods, so Media Script will print a useful error to the user if, for example, image-draw-polygon! is called with a string or a double value for "sides", but won't check to make sure that "sides" is only called with an integer larger than 2. There is no parameter checking in the wrapped procedures (found in wrapper_library.scm). It would help users if someone were to add parameter checking for all of the inkscript functions, using inkscript-documentation as a guide for valid parameter values.
 
Changed:
<
<
  1. Improving methods: There are some methods that we're currently using that need to be wrapped with other functions in order to work correctly. It would be nice to re-write these methods, so the methods just do what we want in the first place.
>
>
  1. Testing/Error messages: Currently, inkscript functions have minimal parameter checking. console.c includes type checking for the functions converted from dbus methods, so Media Script will print a useful error to the user if, for example, image-draw-polygon! is called with a string or a double value for "sides", but won't check to make sure that "sides" is only called with an integer larger than 2. There is no parameter checking in the wrapped procedures (found in wrapper_library.scm). It would help users if someone were to add parameter checking for all of the inkscript functions, using inkscript-documentation as a guide for valid parameter values.
  2. Improving methods: There are some methods that we're currently using that need to be wrapped with other functions in order to work correctly. It would be nice to re-write these methods, so the methods just do what we want in the first place.
 
    1. inkscape_draw_line (image-draw-line-orig!): same problem as inkscape_spiral. Wrapped func: image-draw-line!
    2. inkscape_load (document-load-orig): This method doesn't return a document-id number for the loaded document. A few notes: according to the documentation, this function should load a new image in the place of a given doc. In practice, this function only loads in the place of a doc if that doc is new. Otherwise, the image is loaded in a new window, leaving the given doc open. In our wrapped function, image-load! the image is loaded in a new window, but the function returns a doc-id.
    3. inkscape_move (object-move-orig!): This method only works if the object is already selected. Wrapped func: object-move!
Line: 91 to 100
 
    1. inkscape_selection_paste (selection-paste-orig!): This method doesn't paste the selection to any particular location of the document. The wrapped function isn't ideal, either: it just sends the pasted selection to the origin. Wrapped func: selection-paste!
    2. inkscape_selection_group (selection-group-orig!): This method doesn't return anything, but we want it to return the object id of the group. Wrapped func: selection-group!
    3. inkscape_spiral (image-draw-spiral-orig!): The spiral is drawn in the document's stroke color. If the document's stroke color is "none", the spiral's stroke should default to black. But instead, if the document's stroke isn't set, the spiral just isn't drawn. Wrapped func: image-draw-spiral!
Added:
>
>
  1. Improving wrapped functions: skewX, skewY, and scale.
 

Adding more functions!
Changed:
<
<
  1. Current dbus methods: You may be interested in adding the rest of Soren's dbus methods. We implemented what we considered the most basic/essential inkscape methods, but if inkscript is getting expanded, it might be useful to include layer functions, update functions, the "image" function for importing a jpg image, etc. Once you have the source code for inkscape, and the dbus extension for inkscape, you should be able to find documentation for all of these dbus methods by running inkscape/src/extension/dbus/builddocs.sh. This will build the documentation from xml. If this no longer works (if you're running a newer version of the dbus extension, and this has changed) try looking for a notes or a readme file in inkscape/src/extension/dbus for instructions.
    1. These are the methods that we decided not to implement. We haven't tested them yet.
>
>
  1. Current dbus methods: You may be interested in adding the rest of Soren's dbus methods. We implemented what we considered the most basic/essential inkscape methods, but if inkscript is getting expanded, it might be useful to include layer functions, update functions, the "image" function for importing a jpg image, etc. Once you have the source code for inkscape, and the dbus extension for inkscape, you should be able to find documentation for all of these dbus methods by running inkscape/src/extension/dbus/builddocs.sh. This will build the documentation from xml. If this no longer works (if you're running a newer version of the dbus extension, and this has changed) try looking for a notes or a readme file in inkscape/src/extension/dbus for instructions.
    1. unused methods: these are the methods that we decided not to implement. We haven't tested them yet.
 
      1. layer_change_level
      2. layer_get_all
      3. layer_new
Line: 113 to 123
 
      1. merge_css
      2. node => creates a node.
      3. selection_to_path
Changed:
<
<
    1. These are methods that we wanted to use, but they're broken, and need to be rewritten (as of 7/13/2011)
>
>
    1. broken methods: these are methods that we wanted to use, but they're broken, and need to be rewritten (as of 7/13/2011)
 
      1. close => causes Inkscape to crash
      2. exit => causes Inkscape to crash
      3. object_to_path => causes Inkscape to crash
Line: 122 to 132
 
      1. selection_box => just returns an error message....
      2. undo/redo seem to work in some situations and not others.
      3. selection_get_center => error "no (de)marshaller for GArray type"
Changed:
<
<
  1. Ideas for wrapped functions:_
>
>
  1. Ideas for wrapped functions:
 
    1. object-set-style! and document-set-style!: There are about 101 different wrapped functions you can write with object-set-style! You can set the pattern of the stroke (solid or a type of dash, and the spacing of the dash), the style of the corners, and so on. We only wrapped the most basic of these (setting the color, opacity, and the stroke width). To figure out what style attributes you can set, I would suggest experimenting by hand with many different objects, and then looking at each object's xml. Note that the type of style attributes in "style" depends on the type of object. For example, for text objects, the "style" attribute is used to set attributes like "font-size", "font-weight", and "line-height", as well as the more standard "fill", "fill-opacity", etc.
  1. object-set-attribute! and document-set-attribute!: Likewise, there maybe be some wrapped functions you can write using the set_attribute command. Our notes for inkscape object attributes can be found in InkInkscapeNotes. These notes include all the major attributes for rectangles, ellipses, polygons, and text, but not necessarily all attributes for these objects. Once functions are written to draw stars, calligraphic lines, paths, etc, object-set-attribute! will be a very helpful function for writing object commands for these objects.
  2. image-call-verb!: Look into useful/interesting inkscape verbs you could call with image-call-verb!
Changed:
<
<

  1. Ideas for new inkscape methods (i.e. methods you would have to write yourself for dbus):


move and move_to => only moves the object if the object if already selected, otherwise selects the object filters!

setting the circle: if circle is an arc, it gets the prop "sodipodi:open true", but there's no way to set this attribute- either it's there or it's not. So, we don't have a good way to turn an arc into a pie (but we could to the reverse).
>
>
    1. object-flip!: a function we meant to write, but ran our of time to wrap. Can basically be done with translation and scaling, but figuring out the values to translate/scale by could take a little time to work out.
  1. Ideas for new inkscape methods (i.e. methods you would have to write yourself for dbus):
    1. New tools: Not a comprehensive list, but some of the major tools for inkscape that we are currently missing.
      1. measure tool (just a proc to calculate the distance between two points)
      2. draw box
      3. draw paths/curves
      4. draw with calligraphic brush
      5. spraycan
      6. erase
      7. fill area
      8. color picker
    2. Setting contexts: we're wondering if it would be valuable to write a series of functions that define the context for each tool. For example, calligraphic-brush-context commands to set the type of brush ("wiggly', 'dip pen', 'marker', etc), the width, brush affects like 'thinning', 'angle', etc. In other words, a series of commands that correspond to the toolbar for each tool. For lines and brush-strokes, for example, it seems to make more sense to set the context then set the style of the brush each time you use it, since the user is likely to draw more than one line at a time, and it would be punishing to set the type of brush, the width of the brush, etc, for each individual line. Does it make sense to follow the model of setting-the-context for all objects? Would it be confusing for users to have a set of "context" commands for creating objects, and a set of "object" commands for modifying existing objects?
    3. ellipse-types: setting an ellipse to a segment or an arc. If the ellipse is an arc, it has the attribute 'sodipodi:open' and the value 'true'. So, to get the ellipse to an arc, one can use (object-set-attribute! doc ellipse "sodipodi:open" "true"). But, to set the ellipse to a segment from an arc, one can't just set sopdipodi:open to "false"; one needs to delete the sodipodi:open attribute itself. Currently, we don't have a way to delete attributes.
    4. filters: a series of commands to apply filters, gradients, and patterns. A series of commands to list valid filters, gradients, and patterns. Note that filters, gradients, patterns, etc are assigned urls. So, if an object is filtered, the 'style' attribute of the object will include a 'filter' attribute such as "filter:url(#filter3425)". BUT, the url of a filter changes in each instance of inkscape! So, in one image, #filter3425 might reference the "cubes" filter, and in another image, it might reference the "felt" filter. urls are defined in the xml for a document under . That's about all we know; more experimentation/research needed.
Revision 5
2011-07-13 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
Changed:
<
<
-- KateIngersoll - 2011-07-08
<-- p { margin-bottom: 0.08in; } -->
<-- p { margin-bottom: 0.08in; } -->
>
>
-- KateIngersoll - 2011-07-08
 

Ink Script- Project Timeline
  • Week One:
Changed:
<
<
    • Installing things/setup:

      • got Ubuntu onto computer in Glimmer lab, and onto Kim's computer

      • got Media-Scheme onto computer in Glimmer lab.

      • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.

    • Researching background info:

      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might also be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.

      • Learning about Inkscape, by reading about it, and messing around with it. (Kate) read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application.

      • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images).

    • Inventory: Started to make a list of what commands we wanted to implement.

    • Documenting: Gave a presentation on SVG to the glimmer team.

    • Links:

>
>
    • Installing things/setup:
      • got Ubuntu onto computer in Glimmer lab, and onto Kim's computer
      • got Media-Scheme onto computer in Glimmer lab.
      • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.
    • Researching background info:
      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might also be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.
      • Learning about Inkscape, by reading about it, and messing around with it. (Kate) read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application.
      • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images).
    • Inventory: Started to make a list of what commands we wanted to implement.
    • Documenting: Gave a presentation on SVG to the glimmer team.
    • Links:
 
      • Daily notes from this week:
      • Our initial notes about Inkscape -InkCapabilities
      • Our initial ideas for functions to implement InkProcedures
Line: 21 to 21
 
Deleted:
<
<
 
  • Week Two:
Changed:
<
<
    • Installing things/setup: Gave up trying to install Ubuntu 10.5 on glimmer computer.

    • Researching background info: Finished reading MIT paper (Kate).

    • Wrote Project proposal. This took a surprisingly long time.

    • Links:

>
>
    • Installing things/setup: Gave up trying to install Ubuntu 10.5 on glimmer computer.
    • Researching background info: Finished reading MIT paper (Kate).
    • Wrote Project proposal. This took a surprisingly long time.
    • Links:
 
  • Week Three:
Changed:
<
<
    • Installing things/setup:

      • Set up a Word Press Account- Sam wants us to blog weekly on our project.

      • Installed dbus on Glimmer computer.

    • Researching background info:

      • In contact w/ Soren, (who worked on the 207 Glimmer/Inkscape project). Soren says that since then, he's created an Inkscape service for dbus. So, now our goal is to create our functions by calling the dbus methods Soren's already written (and maybe down the line, writing methods of our own.)

      • Therefore, reading up on what dbus is and how it works.

    • Inventory: continued working on an inventory of commands we'd like to implement. Note that this initial inventory was not really used later in the project (except maybe to help brainstorm ideas) as we had to work off of the functions Soren had already provided.

    • Links:

>
>
    • Installing things/setup:
      • Set up a Word Press Account- Sam wants us to blog weekly on our project.
      • Installed dbus on Glimmer computer.
    • Researching background info:
      • In contact w/ Soren, (who worked on the 207 Glimmer/Inkscape project). Soren says that since then, he's created an Inkscape service for dbus. So, now our goal is to create our functions by calling the dbus methods Soren's already written (and maybe down the line, writing methods of our own.)
      • Therefore, reading up on what dbus is and how it works.
    • Inventory: continued working on an inventory of commands we'd like to implement. Note that this initial inventory was not really used later in the project (except maybe to help brainstorm ideas) as we had to work off of the functions Soren had already provided.
    • Links:
 
  • Week Four:
Changed:
<
<
    • Researching background info:

      • Working on a sample C program that calls a method in dbus, so learn how it works.

      • Working with dbus in d-feet to see what Soren's methods do

      • Eventually, found documentation for Soren's methods can be found by (explain)

    • Inventory: Soren has over 100 methods provided on th inkscape service. We did calls on all of them in d-feet, and sorted them into sections on the wiki: those that were broken, those that we wanted to convert into a Scheme function, those we didn't want to convert (things we thought were either less useful, or too advanced for our initial terminal- layer commands, for example), and things we still didn't understand (before we found Soren's documentation, we had trouble understanding how many functions worked).

    • Programming: With Sam's help, we set up inkscript.c. Sam wrote the framework, and wrote our document-new procedure. We wrote a call to inkscape_draw_rectangle as our first attempt to call a simple inkscape method.

    • Documenting:

>
>
    • Researching background info:
      • Working on a sample C program that calls a method in dbus, so learn how it works.
      • Working with dbus in d-feet to see what Soren's methods do
      • Eventually, found documentation for Soren's methods can be found by (explain)
    • Inventory: Soren has over 100 methods provided on th inkscape service. We did calls on all of them in d-feet, and sorted them into sections on the wiki: those that were broken, those that we wanted to convert into a Scheme function, those we didn't want to convert (things we thought were either less useful, or too advanced for our initial terminal- layer commands, for example), and things we still didn't understand (before we found Soren's documentation, we had trouble understanding how many functions worked).
    • Programming: With Sam's help, we set up inkscript.c. Sam wrote the framework, and wrote our document-new procedure. We wrote a call to inkscape_draw_rectangle as our first attempt to call a simple inkscape method.
    • Documenting:
 
      • wrote blog on MIT paper
      • Presentation to big group on dbus and how it works.
Changed:
<
<
    • Links:

  • Week Five:

    • Programming:

      • In console.c, wrote the calls to all of the dbus methods we decided to convert (by hand). This took a couple days.

      • Wrote documentation for our methods in inkscape.h, and organized procs in inkscape.c and inkscript.h alphabetically by sections (note to future self: it would be better to decide on an order before writing procedures, and it would be better to write documentation as we write the procedures, not after).

      • With Sam's help, set up console.c, the file for converting our C functions in inkscript.c into Scheme functions. To be honest we (Kim and Kate) don't really understand much of this; we know now how to create a Scheme function, and the call to add that function to the environment, but now much else.

      • In console.c, wrote some basic calls to convert inkscape methods we were interested in.

      • (Kate) wrote build_procs, a procedure that partially automated the creation of writing calls in console.c (the calls follow the same basic pattern, so it's not hard to write something like this.)

    • Inventory: looking at our initial inventory, and the methods that we have through dbus, we made a list of functions that we could write by wrapping pre-existing methods. In particular, we were thinking of how to make the dbus methods more user-friendly. Many, for example, take ugly xml-strings as parameters.

    • Links:

>
>
    • Links:
  • Week Five:
    • Programming:
      • In console.c, wrote the calls to all of the dbus methods we decided to convert (by hand). This took a couple days.
      • Wrote documentation for our methods in inkscape.h, and organized procs in inkscape.c and inkscript.h alphabetically by sections (note to future self: it would be better to decide on an order before writing procedures, and it would be better to write documentation as we write the procedures, not after).
      • With Sam's help, set up console.c, the file for converting our C functions in inkscript.c into Scheme functions. To be honest we (Kim and Kate) don't really understand much of this; we know now how to create a Scheme function, and the call to add that function to the environment, but now much else.
      • In console.c, wrote some basic calls to convert inkscape methods we were interested in.
      • (Kate) wrote build_procs, a procedure that partially automated the creation of writing calls in console.c (the calls follow the same basic pattern, so it's not hard to write something like this.)
    • Inventory: looking at our initial inventory, and the methods that we have through dbus, we made a list of functions that we could write by wrapping pre-existing methods. In particular, we were thinking of how to make the dbus methods more user-friendly. Many, for example, take ugly xml-strings as parameters.
    • Links:
 
  • Week Six
Changed:
<
<
    • Programming:

      • Used build_procs to generate calls, added them to console.

      • Wrote some calls by hand, because they took/returned unusual types.

      • Organized calls in console.c alphabetically by section, decided on a consistent naming scheme for our functions, and renamed many functions (note to self: it would be MUCH better to decide on an organization/naming schema first, and then write the functions).

      • Using our wrapper-inventory as a guide, created a file (wrapper_library.scm) to store all of our wrapped functions, and began writing our wrapper functions.

      • Wrote documentation for our functions (both converted and wrapped) in

        inkscript-documentation.

      • Worked on testing all of our functions, fixing bugs in functions and updating documentation as we went.

    • Documentation:

      • Presented to the big group a few methods we'd wrapped so far, explaining our conversion from inkscript.c to console.

    • Links:

      • We are keeping a working log of our functions in InkSchemeProcs (what's written, what's tested, what's documented)

>
>
    • Programming:
      • Used build_procs to generate calls, added them to console.
      • Wrote some calls by hand, because they took/returned unusual types.
      • Organized calls in console.c alphabetically by section, decided on a consistent naming scheme for our functions, and renamed many functions (note to self: it would be MUCH better to decide on an organization/naming schema first, and then write the functions).
      • Using our wrapper-inventory as a guide, created a file (wrapper_library.scm) to store all of our wrapped functions, and began writing our wrapper functions.
      • Wrote documentation for our functions (both converted and wrapped) in inkscript-documentation.
      • Worked on testing all of our functions, fixing bugs in functions and updating documentation as we went.
    • Documentation:
      • Presented to the big group a few methods we'd wrapped so far, explaining our conversion from inkscript.c to console.
    • Links:
      • We are keeping a working log of our functions in InkSchemeProcs (what's written, what's tested, what's documented)
 
  • Week Seven: (no work Mon, Tues, & short day on Fri- short week)
Changed:
<
<
    • Programming:

      • We keep adding functions to wrapper_library as we think of them; other things that we think would be useful.

      • Finished writing all of the calls to dbus that we planned to do.

      • Kept working on documentation in inkscript-documentation

      • Kept working on testing all of our functions.

      • Links:

        • As previously, we are keeping track of all of our functions in InkSchemeProcs

>
>
    • Programming:
      • We keep adding functions to wrapper_library as we think of them; other things that we think would be useful.
      • Finished writing all of the calls to dbus that we planned to do.
      • Kept working on documentation in inkscript-documentation
      • Kept working on testing all of our functions.
      • Links:
        • As previously, we are keeping track of all of our functions in InkSchemeProcs
 
  • Week Eight:
Changed:
<
<
    • Installing things/setup: Our goal for the last three week of the summer is to create a package of all of our work, so that people could easily download and use our console. To this end, Kim is working on installing the programs a person would need on a clean Ubuntu OS, so we can make a list of all the dependencies, etc and make a lovely Makefile.

    • Links:

>
>
    • Installing things/setup: Our goal for the last three week of the summer is to create a package of all of our work, so that people could easily download and use our console. To this end, Kim is working on installing the programs a person would need on a clean Ubuntu OS, so we can make a list of all the dependencies, etc and make a lovely Makefile.
    • Links:
Ink Script- For the Future

The annoying task of fixing things we've done
  1. Testing/Error messages: Currently, inkscript functions have minimal parameter checking. console.c includes type checking for the functions converted from dbus methods, so Media Script will print a useful error to the user if, for example, image-draw-polygon! is called with a string or a double value for "sides", but won't check to make sure that "sides" is only called with an integer larger than 2. There is no parameter checking in the wrapped procedures (found in wrapper_library.scm). It would help users if someone were to add parameter checking for all of the inkscript functions, using inkscript-documentation as a guide for valid parameter values.

  1. Improving methods: There are some methods that we're currently using that need to be wrapped with other functions in order to work correctly. It would be nice to re-write these methods, so the methods just do what we want in the first place.
    1. inkscape_draw_line (image-draw-line-orig!): same problem as inkscape_spiral. Wrapped func: image-draw-line!
    2. inkscape_load (document-load-orig): This method doesn't return a document-id number for the loaded document. A few notes: according to the documentation, this function should load a new image in the place of a given doc. In practice, this function only loads in the place of a doc if that doc is new. Otherwise, the image is loaded in a new window, leaving the given doc open. In our wrapped function, image-load! the image is loaded in a new window, but the function returns a doc-id.
    3. inkscape_move (object-move-orig!): This method only works if the object is already selected. Wrapped func: object-move!
    4. inkscape_move_to (object-move-to-orig!): same problem as inkscape_move. Wrapped_func: object-move-to!
    5. inkscape_selection_paste (selection-paste-orig!): This method doesn't paste the selection to any particular location of the document. The wrapped function isn't ideal, either: it just sends the pasted selection to the origin. Wrapped func: selection-paste!
    6. inkscape_selection_group (selection-group-orig!): This method doesn't return anything, but we want it to return the object id of the group. Wrapped func: selection-group!
    7. inkscape_spiral (image-draw-spiral-orig!): The spiral is drawn in the document's stroke color. If the document's stroke color is "none", the spiral's stroke should default to black. But instead, if the document's stroke isn't set, the spiral just isn't drawn. Wrapped func: image-draw-spiral!

Adding more functions!
  1. Current dbus methods: You may be interested in adding the rest of Soren's dbus methods. We implemented what we considered the most basic/essential inkscape methods, but if inkscript is getting expanded, it might be useful to include layer functions, update functions, the "image" function for importing a jpg image, etc. Once you have the source code for inkscape, and the dbus extension for inkscape, you should be able to find documentation for all of these dbus methods by running inkscape/src/extension/dbus/builddocs.sh. This will build the documentation from xml. If this no longer works (if you're running a newer version of the dbus extension, and this has changed) try looking for a notes or a readme file in inkscape/src/extension/dbus for instructions.
    1. These are the methods that we decided not to implement. We haven't tested them yet.
      1. layer_change_level
      2. layer_get_all
      3. layer_new
      4. layer_next
      5. layer_previous
      6. layer_set
      7. select_all_in_layers
      8. move_to_layer
      9. selection_move_to_layer
      10. pause_updates
      11. resume_updates
      12. update
      13. get_path
      14. image
      15. mark_as_unmodified
      16. merge_css
      17. node => creates a node.
      18. selection_to_path
    2. These are methods that we wanted to use, but they're broken, and need to be rewritten (as of 7/13/2011)
      1. close => causes Inkscape to crash
      2. exit => causes Inkscape to crash
      3. object_to_path => causes Inkscape to crash
      4. get_node_coordinates => causes Inkscape to crash
      5. star =>can't change # sides, or change the orientation, ('arg1', 'arg2', and 'sides' parameters don't change the final shape)
      6. selection_box => just returns an error message....
      7. undo/redo seem to work in some situations and not others.
      8. selection_get_center => error "no (de)marshaller for GArray type"
  2. Ideas for wrapped functions:_
    1. object-set-style! and document-set-style!: There are about 101 different wrapped functions you can write with object-set-style! You can set the pattern of the stroke (solid or a type of dash, and the spacing of the dash), the style of the corners, and so on. We only wrapped the most basic of these (setting the color, opacity, and the stroke width). To figure out what style attributes you can set, I would suggest experimenting by hand with many different objects, and then looking at each object's xml. Note that the type of style attributes in "style" depends on the type of object. For example, for text objects, the "style" attribute is used to set attributes like "font-size", "font-weight", and "line-height", as well as the more standard "fill", "fill-opacity", etc.
  3. object-set-attribute! and document-set-attribute!: Likewise, there maybe be some wrapped functions you can write using the set_attribute command. Our notes for inkscape object attributes can be found in InkInkscapeNotes. These notes include all the major attributes for rectangles, ellipses, polygons, and text, but not necessarily all attributes for these objects. Once functions are written to draw stars, calligraphic lines, paths, etc, object-set-attribute! will be a very helpful function for writing object commands for these objects.
  4. image-call-verb!: Look into useful/interesting inkscape verbs you could call with image-call-verb!

  1. Ideas for new inkscape methods (i.e. methods you would have to write yourself for dbus):


move and move_to => only moves the object if the object if already selected, otherwise selects the object filters!

setting the circle: if circle is an arc, it gets the prop "sodipodi:open true", but there's no way to set this attribute- either it's there or it's not. So, we don't have a good way to turn an arc into a pie (but we could to the reverse).
Revision 4
2011-07-11 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
-- KateIngersoll - 2011-07-08
<-- p { margin-bottom: 0.08in; } -->
<-- p { margin-bottom: 0.08in; } -->
Line: 9 to 9
 
      • got Media-Scheme onto computer in Glimmer lab.

      • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.

    • Researching background info:

Changed:
<
<
      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.

>
>
      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might also be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.

 
      • Learning about Inkscape, by reading about it, and messing around with it. (Kate) read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application.

      • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images).

    • Inventory: Started to make a list of what commands we wanted to implement.

Line: 18 to 18
 
      • Daily notes from this week:
      • Our initial notes about Inkscape -InkCapabilities
      • Our initial ideas for functions to implement InkProcedures
Added:
>
>
 
Revision 3
2011-07-11 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
Changed:
<
<
-- KateIngersoll - 2011-07-08
<-- p { margin-bottom: 0.08in; } -->

Project Timeline
>
>
-- KateIngersoll - 2011-07-08
<-- p { margin-bottom: 0.08in; } -->
<-- p { margin-bottom: 0.08in; } -->
 
Added:
>
>
Ink Script- Project Timeline
 
  • Week One:
Changed:
<
<
  • Installed Ubuntu onto computer in Glimmer lab, and onto Kim's computer.
    • Installed Media-Scheme onto computer in Glimmer lab.

    • Searched for articles that related to our project. (See list below). To be honest, the MIT paper is useful, but I don't think we read any of the other articles; they seemed to only have a tangential connection to our project. Articles can be found at InkArticles.

>
>
    • Installing things/setup:

      • got Ubuntu onto computer in Glimmer lab, and onto Kim's computer

      • got Media-Scheme onto computer in Glimmer lab.

 
    • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.

Changed:
<
<
    • Read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application. Started thinking about our goals: what commands we want to implement.

    • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images). Gave a presentation on SVG to the glimmer team.

>
>
    • Researching background info:

      • Searched for articles that related to our project. To be honest, we didn't end up using most of what we found. The only article I can recommend reading is the MIT paper. It might be useful to look at the sources that the 2007 InkScript team used, but we never go around to it.

      • Learning about Inkscape, by reading about it, and messing around with it. (Kate) read through Ch 1. and Appendix A in The Book of Inkscape for some background for the application.

      • Researched SVG images, and HTML XML formatting (which inkscape uses to define objects and images).

    • Inventory: Started to make a list of what commands we wanted to implement.

    • Documenting: Gave a presentation on SVG to the glimmer team.

    • Links:

 
  • Week Two:
Changed:
<
<
    • Finished reading MIT paper.

    • Gave up trying to install Ubuntu 10.5 on glimmer computer.

    • Wrote Project proposal.

>
>
    • Installing things/setup: Gave up trying to install Ubuntu 10.5 on glimmer computer.

    • Researching background info: Finished reading MIT paper (Kate).

    • Wrote Project proposal. This took a surprisingly long time.

    • Links:

 
  • Week Three:
Changed:
<
<
    • Working on an inventory of commands: commands we'd like to implement.

>
>
    • Installing things/setup:

 
    • Set up a Word Press Account- Sam wants us to blog weekly on our project.

Deleted:
<
<
    • In contact w/ Soren, says that he's created an Inkscape service for dbus. Change in our project goals: new goal is to implement commands using the dbus services Soren's provided.

    • Researching dbus and how it works.

 
    • Installed dbus on Glimmer computer.

Added:
>
>
    • Researching background info:

      • In contact w/ Soren, (who worked on the 207 Glimmer/Inkscape project). Soren says that since then, he's created an Inkscape service for dbus. So, now our goal is to create our functions by calling the dbus methods Soren's already written (and maybe down the line, writing methods of our own.)

      • Therefore, reading up on what dbus is and how it works.

    • Inventory: continued working on an inventory of commands we'd like to implement. Note that this initial inventory was not really used later in the project (except maybe to help brainstorm ideas) as we had to work off of the functions Soren had already provided.

    • Links:

 
  • Week Four:
Changed:
<
<
    • Wrote blog on MIT paper

>
>
    • Researching background info:

 
    • Working on a sample C program that calls a method in dbus, so learn how it works.

Deleted:
<
<
    • Presentation to big group on dbus and how it works

 
    • Working with dbus in d-feet to see what Soren's methods do

Changed:
<
<
    • Eventually, found documentation for Soren's methods

    • Sorting methods: those we will convert, those we won't, those we don't understand, those that are broken.

    • With Sam's help, set up inkscript.c

  • Week Five:
    • Wrote the calls to the inkscape methods we were interested in (by hand)

    • Wrote the documentation for our methods in inkscape.h, and organized procs in inkscape.c alphabetically by sections.

    • With Sam's help, set up console.c

    • Made a list of functions that we could write by wrapping per-existing methods.

    • Wrote some calls to inkscape methods we were interested in, and wrote build_procs, a procedure that partially automated the creation of writing calls.

>
>
      • Eventually, found documentation for Soren's methods can be found by (explain)

    • Inventory: Soren has over 100 methods provided on th inkscape service. We did calls on all of them in d-feet, and sorted them into sections on the wiki: those that were broken, those that we wanted to convert into a Scheme function, those we didn't want to convert (things we thought were either less useful, or too advanced for our initial terminal- layer commands, for example), and things we still didn't understand (before we found Soren's documentation, we had trouble understanding how many functions worked).

    • Programming: With Sam's help, we set up inkscript.c. Sam wrote the framework, and wrote our document-new procedure. We wrote a call to inkscape_draw_rectangle as our first attempt to call a simple inkscape method.

    • Documenting:

      • wrote blog on MIT paper
      • Presentation to big group on dbus and how it works.
    • Links:

  • Week Five:

    • Programming:

      • In console.c, wrote the calls to all of the dbus methods we decided to convert (by hand). This took a couple days.

      • Wrote documentation for our methods in inkscape.h, and organized procs in inkscape.c and inkscript.h alphabetically by sections (note to future self: it would be better to decide on an order before writing procedures, and it would be better to write documentation as we write the procedures, not after).

      • With Sam's help, set up console.c, the file for converting our C functions in inkscript.c into Scheme functions. To be honest we (Kim and Kate) don't really understand much of this; we know now how to create a Scheme function, and the call to add that function to the environment, but now much else.

      • In console.c, wrote some basic calls to convert inkscape methods we were interested in.

      • (Kate) wrote build_procs, a procedure that partially automated the creation of writing calls in console.c (the calls follow the same basic pattern, so it's not hard to write something like this.)

    • Inventory: looking at our initial inventory, and the methods that we have through dbus, we made a list of functions that we could write by wrapping pre-existing methods. In particular, we were thinking of how to make the dbus methods more user-friendly. Many, for example, take ugly xml-strings as parameters.

    • Links:

 
  • Week Six
Added:
>
>
    • Programming:

 
    • Used build_procs to generate calls, added them to console.

Changed:
<
<
    • Wrote some more calls by hand, because they took/returned unusual types.

    • Presented to the big group a few methods we'd wrapped so far, explaining our conversion from inkscript.c to console.c

    • Organized calls in console.c alphabetically by section, decided on a consistent naming scheme for our functions, and renamed many functions.

    • Wrote many wrapper functions in wrapper_functions.

    • Wrote documentation for our functions in inkscript-documentation

    • Worked on testing all of our functions, changing functions and documentation as we went. Recording our functions in InkSchemeProcs

>
>
      • Wrote some calls by hand, because they took/returned unusual types.

      • Organized calls in console.c alphabetically by section, decided on a consistent naming scheme for our functions, and renamed many functions (note to self: it would be MUCH better to decide on an organization/naming schema first, and then write the functions).

      • Using our wrapper-inventory as a guide, created a file (wrapper_library.scm) to store all of our wrapped functions, and began writing our wrapper functions.

      • Wrote documentation for our functions (both converted and wrapped) in

        inkscript-documentation.

      • Worked on testing all of our functions, fixing bugs in functions and updating documentation as we went.

    • Documentation:

      • Presented to the big group a few methods we'd wrapped so far, explaining our conversion from inkscript.c to console.

    • Links:

      • We are keeping a working log of our functions in InkSchemeProcs (what's written, what's tested, what's documented)

 
  • Week Seven: (no work Mon, Tues, & short day on Fri- short week)
Changed:
<
<
    • Finished writing the calls to dbus that we planned to do.

    • Finished documenting (virtually) all of our functions.

    • Almost finished testing all of our functions.

>
>
    • Programming:

      • We keep adding functions to wrapper_library as we think of them; other things that we think would be useful.

      • Finished writing all of the calls to dbus that we planned to do.

      • Kept working on documentation in inkscript-documentation

      • Kept working on testing all of our functions.

      • Links:

        • As previously, we are keeping track of all of our functions in InkSchemeProcs

  • Week Eight:
    • Installing things/setup: Our goal for the last three week of the summer is to create a package of all of our work, so that people could easily download and use our console. To this end, Kim is working on installing the programs a person would need on a clean Ubuntu OS, so we can make a list of all the dependencies, etc and make a lovely Makefile.

    • Links:

Revision 2
2011-07-10 - Main.KateIngersoll
Line: 1 to 1
 
META TOPICPARENT name="DailyNotesInkscape"
-- KateIngersoll - 2011-07-08
<-- p { margin-bottom: 0.08in; } -->

Project Timeline

  • Week One:
Changed:
<
<
    • Installed Ubuntu onto computer in Glimmer lab, and onto Kim's computer

>
>
  • Installed Ubuntu onto computer in Glimmer lab, and onto Kim's computer.
 
    • Installed Media-Scheme onto computer in Glimmer lab.

    • Searched for articles that related to our project. (See list below). To be honest, the MIT paper is useful, but I don't think we read any of the other articles; they seemed to only have a tangential connection to our project. Articles can be found at InkArticles.

    • Set up wiki pages for this project. Originally, we meant to log what we accomplished each day, but that fell to the wayside as we actually began to program.

 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback