Split sugar-toolkit out of sugar shell.

6 files changed, 0 insertions, 394 deletions

diff --git a/docs/GPL-C.txt b/docs/GPL-C.txt
deleted file mode 100644
index aa909b4..0000000
--- a/docs/GPL-C.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * Copyright (C) 2006, Red Hat, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
diff --git a/docs/GPL-python.txt b/docs/GPL-python.txt
deleted file mode 100644
index 96e81d1..0000000
--- a/docs/GPL-python.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-# Copyright (C) 2006, Red Hat, Inc.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
-
diff --git a/docs/LGPL-C.txt b/docs/LGPL-C.txt
deleted file mode 100644
index 88798f8..0000000
--- a/docs/LGPL-C.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * Copyright (C) 2006, Red Hat, Inc.
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the
- * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
- * Boston, MA 02111-1307, USA.
- */
diff --git a/docs/LGPL-python.txt b/docs/LGPL-python.txt
deleted file mode 100644
index 1db1ea4..0000000
--- a/docs/LGPL-python.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright (C) 2006, Red Hat, Inc.
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the
-# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-
diff --git a/docs/controls.txt b/docs/controls.txt
deleted file mode 100644
index 52591ea..0000000
--- a/docs/controls.txt
+++ /dev/null
@@ -1,199 +0,0 @@
-Colors
-
-Black - palettes, popups
-Toolbar Grey #262626 - toolbars, expanded palette
-Button Grey #808080 - buttons
-Selection Grey #A6A6A6 - selection, expanded panels
-Panel Grey #C0C0C0 - panel, desktop
-Text field Grey #E5E5E5 - text field background
-White - pressed states and multiline text areas
-
-States
-
-Default - gtk.STATE_NORMAL
-Focused - gtk.STATE_SELECTED
-Pressed - gtk.STATE_ACTIVE
-Hover - gtk.STATE_PRELIGHT
-Inactive - gtk.STATE_INSENSITIVE
-
-gtk.Button
-
-* The image should work the same of the image button
-* Need to write a theme to match the visual style
-* Cancel should never be default because you can always activate it with Esc
-* Radius should be 1/2 of the control height
-* Write a list of stock icons people should use and replace them in the theme to match our visual style
-
-sugar.Icon
-
-* Used in canvas-like views so probably an Hippo item.
-* Svg Only.
-* It should support xo colors easily.
-* Rollovers with a focus mark.
-
-sugar.IconButton
-
-* Support for SVG and png.
-* Icons should be grey scale. But might be coloured with the XO colors (svg only)
-* Size of the button is 75 pixels, size of the icon canvas is 55 and suggested icon size is around 45.
-* States, defaults:
-    Hover : Black
-    Pressed : Rounded rectangle 61 pixels, 10 pixels of radius, filled in selection grey
-    Focused : Rounded rectangle 61 pixels, 10 pixels of radius, stroked in white 2.25 points
-    Inactive. Fallbacks if no inactive icon is specified.
-        Svg: Remove the fill and render the stroke in button grey
-        Png: just do some effect on the pixbuf, which also work for grey icons
-* You can set an icon for each states which replace the default except for the Hover state of buttons which has rollover.
-* "palette" boolean property. If true show an arrow active immediately on click (but also on hover)
-
-sugar.ToolButton (support for rollovers)
-
-* Contains IconButton
-* There is no palette but a tooltip.
-* Normal: Button grey rounded filled rectangle
-* Inactive: Button grey rounded stroked rectangle
-    
-sugar.ToggleIconButton
-
-* Toggled should be like Pressed
-* Inconsistent should be the same of Default (the action depend on the cases)
-* Pressed state and Toggled state is Selection grey
-
-sugar.ToolIconButton
-
-* Contains a ToggleIconButton
-
-gtk.CheckButton
-
-* Match the visual design, shoul be possible with just theme changes
-
-gtk.RadioButton
-
-* Exactly like CheckButton just a different indicator
-
-gtk.OptionMenu
-
-* Match the visual style. Hopefully only theme changes.
-* Add the scroll thing.
-* Groups. Either by a normal separator or a titled separator.
-* Optional support for showing just the icon from the menu (maybe, low priority)
-* Allow fixed sizing of the "button" and ellipsize the label
-
-sugar.Entry
-
-* Support for packing icons before and after the entry. Extend gtk.Entry.
-* Activate/Cancel functionality.
-    Two buttons at the end to the entry and key bindings (Esc and Enter). They are visible only when there are changes.
-    The icons appear only when the field is focused and the content is changed since it gained focus.
-    When hitting escape revert and select all the text.
-
-gtk.ComboxBox
-
-* We miss accept/cancel functionality. Probably patch gtk to allow to replace the entry in the combo box with sugar.Entry.
-
-sugar.SearchEntry
-
-* Use sugar.Entry
-* Search button on the left. Clicking should focus the entry.
-* Cancel button (Esc) on the right, always visible when there is text in the entry. Clicking it will clear the text and focus the textfield.
-* Activate button (Enter) on the right displayed when the content of the text field changed from the last focus or activation.
-* While activating:
-    the Activate button becomes a Spinner.
-    clicking the close button also cancel the search.
-* When activation is completed:
-    The spinner goes away.
-    We *don't* clear the entry but we select the text.
-* Search can either be incremental or on activation. For incremental there is no Accept button. start_spinning and stop_spinning to control the spin icon. start would only spin for an amount of time decided by the widget itself (and documented).
-* The suggestions list is provided by the application. Need to figure out which api to use, either model or signal based.
-* Default implementation of suggestions which automatically save the latest searches.
-
-sugar.DateSelector
-sugar.DateComboBox (lower priority)
-
-* Pluggable calendar implementation to support different kind of calendars (localization).
-* Might reuse gtk.Calendar. We should unify month/year selectors and accellerate the movement gradually.
-
-gtk.SpinButton
-
-* Make it match the visual design, hopefully just theme changes
-
-sugar.ToolItem
-
-* Optional label, either text or icon
-* Used for example to have a label near a SpinButton. Clicking on the label should focus the spin button.
-
-gtk.ProgressBar
-
-* Make it match the visual design, hopefully just theme changes.
-* For determinate progress bars should we always pulse to show that there is activity (power consumption? necessary feedback?)
-* Do not use text inside the progress bar
-
-sugar.Spinner
-
-* pulse() call to keep it running with a timeout
-* stop()
-
-gtk.Range (or sugar.Slider?)
-
-* Property to show the fill in white color, probably default on.
-* Draw the discrete steps.
-* For colored sliders, subclass gtk.Range and add a gradient.
-
-sugar.LevelIndicator
-
-* Set the number of blocks
-* Set the level as percentage
-* Property for discrete or not
-* We can probably use a GtkAdjustment for most of the above.Rollovers
-
-
-gtk.TextView
-
-gtk.ScrolledWindow
-
-* Theme it to match the visual.
-
-sugar.ScrolledWindow
-
-* Support for markers. Line as default and optional support for other shapes (star for bookmarks, circles for xos...). Generic way of add marks and keep them updated (observer?)
-
-gtk.Expander
-
-gtk.Separator
-
-sugar.GroupBox
-
-* just a container
-* set_title and set_title_widget (checkbox, radiobutton...)
-* different color and separator under title
-
-gtk.TreeView
-
-gtk.Notebook
-
-* Expand to fill the whole space by default but property to turn it off
-* Switching tabs with the little arrows should page
-
-Palettes in ToolIconButton, IconButton
-* Inmediately on rollover, show the black background.
-* After a very short delay, show the primary state (name of the action and key shortcut).
-* After a bigger delay, show the popup secondary state.
-* Could be animated.
-* Menu Items would go on the top and then the free-form rollover content.
-* The popup would be a gtk.Window that contains a Label, a MenuShell, an hippo.Canvas (or whatever) and finally a button bar (OK/Cancel).
-* The popup will have a setPrimaryState(label, accelerator) method. For action buttons would be a MenuItem, for the others would only be a Label.
-* The primary state should already have the same width as the secondary state and the expandable areas.
-* Primary states appear and disappear automatically (with a short delay). A click outside makes it disappear instantly.
-* Secondary states appear after a delay, or with a single click on the icon. 
-* Secondary disappears with the esc key, clicking outside the popup or clicking on a button inside.
-
-Toolbox    
-* When an activity opens, the activity tab should be opened and the focus on the activity title.
-* We must provide an activity tab in the toolbox and would be good to also provide an standard Edit tab.
-
-Grab key
-* We probably will need the grab mode.
-* Highlight the scrollbar in the view the pointer is (the view that will scroll when moving the pointer).
-
-Clipboard
-* Window manager to handle in an invisible window in every corner and forward the events when they are not in the corner, or use XEvIE (X Event Interception Extension).
diff --git a/docs/design.txt b/docs/design.txt
deleted file mode 100644
index 37061af..0000000
--- a/docs/design.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-= Frame =
-
-== Activation and deactivation ==
-
-* Immediately access the frame by hitting any corner pixel (the exact corner point)
-* Hitting any of the screen edges activate the frame after 0.5s delay
-* Pressing and holding the frame key activate the frame until the key is released.
-* Pressing the frame key momentarily toggle the frame. To deactivate it another key press is necessary.
-
-= IRC logs =
-
-Frame
-
-eliason marcopg:  First, you can immediately access the frame by hitting any corner pixel.
-dcbw marcopg: I think that's the issue, yes
-eliason Second, you can activate it from any edge, but there is a half second delay.  In addition to the delay, the timer on the delay only ticks when the mouse is on an edge pixel and also below some threshold velocity, so if the mouse is moving it will not show up.
-eliason marcopg: Third, there will be a frame key.  Pressing and holding this key will invoke the frame until the key is released.  Pressing this key momentarily, however, will toggle the frame and keep it in view until the key is pressed again.
-eliason marcopg:  All of these things are implemented in Flash (The frame key is 8, I think...), with the exception of the mouse velocity threshold on the edges.
-eliason marcopg:  The only other minor usability issue I could see is adding a hit area in the corners.  That is, once the frame is out, have an invisible triangle in each corner that is still considered part of the frame, so that rolling out of the frame to get from one edge to another doesn't hide the frame, by accident.  In fact, doing this would make the delay on hide unnecessary.
-eliason marcopg:  Oh, and other important edges case to think about on the frame:  1)  When someone is dragginan object (XO, file, image, etc) the frame should come out prematurely and without delay (maybe once within a large grid cell of the edge) and highlight to indicate where the object could be dropped.  2)  When the search field is active, the frame should remain out even if the mouse isn't over it.  Only when the search is cleared should it hide again.
-eliason marcopg:  The rollover states are as follows:  1)  Immediate rollover is a black square in the frame cell itself.  2)  Very shortly thereafter (about 1/4 sec) Is the Primary information label and 3) a bit longer after that (about 1/2 sec) the extended panel appears with additional info.
-
-Menu
-
-eliason marcopg:  Deactivation is instantaneous at the moment, but again, based on testing with the software we may want to add a very short delay.  Also, we may want again to have a invisible triangles between the grid cell in the frame and the extended panel.
-eliason Delay between mouse rollover and showing black square:  0
-eliason Delay before primary info animation begins: 1/10 sec
-eliason Duration of primary info extension animation:  1/5 sec
-eliason Delay from end of primary info animation until secondary info:  1/2 sec
-Duration of secondary info animation: 1/5 sec
-
-Text layout
-
-eliason marcopg:  Well, first of all, in the latest screens which we haven't sent out yet, the primary info rollover is designed to fit the text to the nearest microgrid, regardless of the size of the secondary info panel.  The second animation segment will both extend the width and height to fit.
-eliason marcopg:  As far as cutoff goes, I think that's a reasonable solution.  We should allow the primary info text to be as long as the secondary info panel, and beyond that an ellipsis would be a good way to go, though hopefully designers are strongly encouraged NOT to let that happen.
-eliason marcopg:  However, there may be cases when we don't want that to happen. I can think of one, which you haven't seen yet:  "Invite with X X X X X."  The new activity/invite rollover might have the XOs who you are implicitly inviting to start an activity with listed, and we couldn't cut that off (Though we CANget around it and list, say, a max of three people and then indicate that there are 5 more not shown, etc.)
-eliason marcopg:  Right.  I think that, in most cases, there should be some template for it.  If the designer is creating a GUI for an application and making toolsets (such as the color chooser), then we know how big all of those are.  Things like "just text" will mostly show up in OS applications like the clippings and such, so we can just pick a preferred size that shows enough text to be meaningful without compromising too much of the screen.
-
-Mesh view
-
-eliason marcopg:  also important regarding the results:  the fill color should be the background color, so they look like outlines, and the line color should be near enough to the background to make them less contrasty.  Also, all XOs in the result set should be z-sorted to the front of their groups.  That's key.
-eliason marcopg:  The activity icons and XOs are treated separately, so it may be the case that several XOs in a group match the search but the activity their in doesn't, and they would be grayed out independently.
-eliason marcopg:  yes, only the color change.  Colored stuff is the result.  We don't want to actually make things disappear.
-
-
-Mesh discussion
-
-eliason marcopg:  Well, the terminology we're now using for the zoom level labels is:  My Activities, My Friends, My Neighbors.
-eliason marcopg:  Alright, true, so the working terminology (not the labels for the search field, but still used by all of us) is: home, friends, mesh
-eliason marcopg:  If you treat each frieeliason marcopg:  If you treat each friend or group as a node in a graph, and each edge in the graph as a spring, you can let the system reach an equilibrium using a basic physics simulation that will spread the nodes out evenly.nd or group as a node in a graph, and each edge in the graph as a spring, you can let the system reach an equilibrium using a basic physics simulation that will spread the nodes out evenly.
-eliason marcopg:  If you treat each friend or group as a node in a graph, and each edge in the graph as a spring, you can let the system reach an equilibrium using a basic physics simulation that will spread the nodes out evenly.
-eliason marcopg:  There's lots of info on this type of thing online.  To do it right within a given box, you also have to add anchored springs at the corners and such to stretch the whole thing out to fill the space.
-eliason OK, so another basic idea is to keep a very rough downsampled grayscale image around....
-eliason The grayscale value would map to the number of XOs within the grid cell on screen.
-eliason marcopg:  Then, when placing a new one you could just find the best place to place it , though now that I think about it that would probably require a simulated annealing algorithm or something else clever to do...
-marcopg eliason, do you mean macro cell here?
-marcopg i.e. every buddy would be placed in one macro cell
-eliason marcopg:  Well, actually I guess you'd kind of want a blurred brayscale image, where each object placed represents a white circle, but with a gaussian blur so that it acts like a topographic map of the mesh.
-eliason marcopg:  The white spots would be dense, like hills, the black spots would be void of people, like holes.  Then to place a new one, you kind of roll a simulated marble around until you find a good hole to place it in...
-eliason marcopg:  And, yet another idea, which could be used in conjunction with or independent of the above.  You could simply place a small repulsive force between the objects, so that they push each other apart slightly.  You could just place at random and have them adjust accordingly.  This works very much like the spring model, though.
-eliason Of course, the drawback of the third idea is that it's n^2 in the number of groups on the mesh, but that number should never be that large.
-eliason The spring model is a little more complicated, but you only have to place springs between nearby objects, which reduces that somewhat.
-eliason marcopg:  But actually, I think #3 might be the easiest to implement, and work just as well.  It works nicely since it could still allow you to drag them around and the rest of the mesh would react naturally.  In the spring model, you'd have to dynamically add and break spring connections when a node is moved around.
-marcopg eliason, mm was just thinking about this would interact with custom placed nodes...
-marcopg eliason, I never done something similar before so I will really need to play a bit with it...
-eliason marcopg:  Also, #3 is more forgiving:  In the spring model, placing one new node will move EVERY node in the mesh somewhat, if even just a small amount, since the whole system adjusts.  With the repulsion force, only nearby nodes would be affected, except of course through a chain reaction...
-eliason marcopg:  I'm sure we can find documentation.  Basically, you calculate the distance between the two nodes (pythag) and if that distance is less than some threshold you compute the angle between them (atan2) and then you give each one a small repulsive acceleration, and update each frame by treating each with its own acceleration, velocity, and position.
-eliason marcopg:  radiusConstant + (numXos*radiusScale) + ((index%3)*offsetScale)  <-- that gets pretty close to what I'm working with now.
-eliason marcopg:  One addition:  When the groups are small, we don't want to add the snowflake effect, since they fit in neat geometric shapes around the ring.  So we get....actually, here's the ugly line of code:     radius = 25 + .3*(Math.max(participants.length-10,0)) + (i%3)*.5*(Math.max(participants.length-10,0));
-eliason marcopg:  The added ugliness is a bit of code that zeros out the 2nd two quantities if there are less than 10 people in the group.  You could just place them in an if block actually, but I'd done it this way in case I wanted to change the thresholds independently...eliason marcopg:  The added ugliness is a bit of code that zeros out the 2nd two quantities if there are less than 10 people in the group.  You could just place them in an if block actually, but I'd done it this way in case I wanted to change the thresholds independently...
-eliason marcopg:  OK, cool.  The animation is a simple easing algorithm:   position += (targetPostition - position)*percentage.
-eliason marcopg:  Well, that's a function of the radius and the angle computed from above.  targetX = radius*cos(angle), targetY = radius*sin(angle), for each XO.
-marcopg eliason, aaah I see now
-
-eliason marcopg:  The basic problem is that people are crossing an index that is a multiple of the mod, so everyone shifts in and out.  What if, instead, we adjusted the indeces of every XO with an index of  modValue*c greater than the XO that left, and subtract modValue from each of their indices?
-eliason With mod 3, we basically have 3 levels of the ring.  This solution would just shift ONE of those rings couter-clockwise one XO position, leaving the other two rings intact as is.  We move many fewer XOs than before, but we minimize the movement any given XO has to make by spreading it across the ring level instead of moving the last XO all the way across the circle...eliason marcopg:  The basic problem is that people are crossing an index that is a multiple of the mod, so everyone shifts in and out.  What if, instead, we adjusted the indeces of every XO with an index of  modValue*c greater than the XO that left, and subtract modValue from each of their indices?
-eliason With mod 3, we basically have 3 levels of the ring.  This solution would just shift ONE of those rings couter-clockwise one XO position, leaving the other two rings intact as is.  We move many fewer XOs than before, but we minimize the movement any given XO has to make by spreading it across the ring level instead of moving the last XO all the way across the circle...
-eliason marcopg:  The final detail of that, beyond shifting each index down by the mod value, is to shift the very last group of people in the ring down to fill all the holes, if you get my meaning...
-
-Activity startup feedback
-
-I agree we certainly need feedback for this sort of thing.  For
-starters, the icon of the selected activity should immediately appear
-in the ring.  Perhaps we can apply some small animation to this
-activity icon to indicate that it is starting up.  Marco, could you
-use HSV for the icon color, and modulate the S(aturation) on a sin
-curve so the color pulses betwen, say, 0 and 192 until the activity
-starts, at which point it slides up to 255?
-
-Clipboard
-
-<marcopg> eliason, when should the frame be automatically showed? when
-starting the drag or when hitting the corner
-<marcopg> eliason, (the first one would be tricky to implement)
-<eliason> marcopg:  Initially we wanted it to happen on drag, but after
-thinking about this more, it's a bad idea, since it would hide the toolbars,
-and some activities may have toolbars that support drag and drop also.  As
-such, we probably just keep the hot corners as is, and perhaps implement the
-"warm edges" too, but only when dragging...
-<marcopg> eliason, which reminds me... the plan is to completely drop edges at
-this point? or at least give it a try? (for the not dragging case)
-<eliason> I still think it's worth trying, but I think the general consensus
-was that we should drop it.  That's also the easier option, so for now, I
-guess it's fine.
-<marcopg> ok
-<marcopg> eliason, what should be the title of the clipboard rollover? (we are
-trying to get text objects right for now, but if you have general ideas...)
-<eliason> marcopg: Well, it would depend on what is in the clipboard.  For
-instance, if I copy some text, it should say "text clipping", or if I copy an
-image it should say "picture clipping"
-<marcopg> eliason, so [name of the object] + clipping?
-<eliason> marcopg:  If it is an activity object, it should be the name of the
-object i.e. "Eben's Shark Drawing", etc.
-<marcopg> oh ok
-<eliason> It's only a clipping if it is part of another larger context.
-<eliason> If the whole thing is an object itself, we use the object's name.
-<marcopg> eliason, I see now
-<marcopg> eliason, we want a preview of the objectm right? For text, should we
-show part of the text in the rollover?
-<eliason> marcopg: yeah, probably the first n characters of it, with an
-ellipsis at the end.
-<marcopg> eliason, on multiple lines I guess?
-<marcopg> something like, 4 lines of text on a 2 grid cells large menu, and
-ellipsize after that
-<marcopg> (the exact numbers doesn't matter, just the logic
-<eliason> marcopg:  Right.