Inkscape

Hi,

Student Application deadline is extended to 16:00 UTC March 27, 2007.

http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/7a95180a7dbeee9

Alexandre

On Mon, 26 Mar 2007, Gail Banaszkiewicz wrote:

> Subject: Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
>
> I'm pretty sure I already got schooled on this ;)

Apologies.  Difficult to read the whole thread before replying.

Almost pointed out how the people praising the GIMP or Sodipodi and the
many undocked windows were usually using multi head setups or at least
lots of virtual deskspaces but again that consideration has already been
mentioned.

Eagerly awaiting comment from Bulia on how he thinks a Tabbed interface
can coexist with the need to show multiple pages (not yet in SVG but
already in PDF and OpenDocument Draw).

-- 
Alan

I'm pretty sure I already got schooled on this ;)

Alan Horkan wrote:
> That screenshot is a classic example of Multiple Document Interface (MDI).
> Microsoft Word abandoned this approach in about 2000 (if I recall
> correctly, possibly earlier) as the concept of a single document per
> window was/is considered easier for users to grasp.

Only a few words :P :
I think the best option about "to dock or not dock" is to let the user 
choose between them. That's IMHO the best decision.

On Mon, 26 Mar 2007, Gail Banaszkiewicz wrote:

> bulia byak wrote:
> > I'm afraid there are many who are used to the
> > current behavior (e.g. for viewing documents or views of the same
> > document side by side).
> Personally I have always preferred the model where there is one
> encompassing program window, and then sub windows contained within it.
> I can't stand millions of separate windows (i.e. GIMP).  The taskbar
> only shows one item for the program instead of one for each document
> open.  If the tabs you are talking about could be "minimized" (using the
> term loosely) you could achieve the side-by-side behavior.
>
> Here is a screen shot showing what I mean:
> http://gbanaszk.oasis.nexus.carleton.ca/SummerOfCode/docsSideBySide.png

That screenshot is a classic example of Multiple Document Interface (MDI).
Microsoft Word abandoned this approach in about 2000 (if I recall
correctly, possibly earlier) as the concept of a single document per
window was/is considered easier for users to grasp.  You might recall
marketing and to a lesser extent usability* are strengths of Microsoft,
love them or loathe them.

(Boring explanation to follow to hopefully avoid ambiguity in the
disctussion:

What the GNU Image Manipulation Program (GIMP) does is very specifically a
Controlled Single Document Interface (CSDI), where the toolbox acts as the
main control window.

Applications ported from the Macintosh to Windows often use a Controlled
Single Document Interface but more often the Menu bar window acts as the
main control window.

Inkscapes uses a Single Document Interface much closer to what the rest of
Gnome users.)

Hope that helps

-- 
Alan

* Usability but in the sense of sticky and easy to get into usability if
not real long term usability and effienciency in many cases.

On Mar 26, 2007, at 1:58 PM, Gail Banaszkiewicz wrote:

> I only show the windows side my side to say that it is possible.  Tabs
> would make me happier in the end, like how Dreamweaver works (at least
> in MX 2004, my latest version).  I just personally hate having  
> multiple
> items on the task bar for one piece of software - I find it  
> irritating.
> Probably has a lot to do with using Windows more than Linux and not
> having multiple desktops.  Or maybe I'm just old school.

Oh, that's a completely separate item.

Tabbed work is a slight difference, but then if you only care about  
multiple items, Windows provides for having those collapsed. Also,  
additionally windows can be flagged to not show up as top level.

I only show the windows side my side to say that it is possible.  Tabs 
would make me happier in the end, like how Dreamweaver works (at least 
in MX 2004, my latest version).  I just personally hate having multiple 
items on the task bar for one piece of software - I find it irritating.  
Probably has a lot to do with using Windows more than Linux and not 
having multiple desktops.  Or maybe I'm just old school.

I'm wing-tip on IRC btw :)

Jon A. Cruz wrote:
> What you are describing there is classic MDI, and was officially 
> deprecated on Windows back when Microsoft first introduced Windows 95.
>

Dear Inkscape developers,

My name is Christopher Brown, and I have just submitted my application to
the Google Summer of Code for Inkscape.

My abstract follows in this message, and my full project description can be
found at this location: http://audiere.googlepages.com/gsoc-description.pdf

"Inkscape was built purely as a vector editor =96 a GUI, you might say, for
SVG. But the need has arisen for raster capabilities within the Inkscape
application. Previous to this capability, the user would have to perform
such raster post-production in a different application, such as the GIMP or
Photoshop. Often this may not be anything more complicated than a
punch/explosion effect or a windswept filter. This can be accomplished by
integrating these effects, especially those provided by ImageMagick,
directly into the Inkscape interface. The results will not be SVG,
unfortunately, but they will be bitmaps, as the user desires."

I hope soon to be working with you guys,

-Chris

I have a dual monitor setup on my desk. I prefer to maximize the main 
window on one monitor and have the tools also on the other.

I do not want to minimize the effective canvas size by other childs.

just my 2 cents,

Adib.
---
Bryce Harrington schrieb:
> On Mon, Mar 26, 2007 at 02:25:29PM -0400, bulia byak wrote:
>> By the way, one way to resolve this issue would be to go even further
>> in UI redesign and abandon separate windows altogether, instead adding
>> tabs to the main interface for open documents. I personally would
>> welcome this, although I'm afraid there are many who are used to the
>> current behavior (e.g. for viewing documents or views of the same
>> document side by side).
> 
> I'm fairly certain that abandoning separate windows would meet with a
> great deal of criticism.  Recalling some of the SDI/MDI debates from
> early on the project I'm fairly certain there are strong feelings on
> this topic.  ;-)
> 
> Bryce
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 

On Mar 26, 2007, at 11:34 AM, Gail Banaszkiewicz wrote:

> Personally I have always preferred the model where there is one
> encompassing program window, and then sub windows contained within it.
> I can't stand millions of separate windows (i.e. GIMP).  The taskbar
> only shows one item for the program instead of one for each document
> open.  If the tabs you are talking about could be  
> "minimized" (using the
> term loosely) you could achieve the side-by-side behavior.
>
> Here is a screen shot showing what I mean:
> http://gbanaszk.oasis.nexus.carleton.ca/SummerOfCode/ 
> docsSideBySide.png

Hi Gail,

What you are describing there is classic MDI, and was officially  
deprecated on Windows back when Microsoft first introduced Windows 95.

There had been reasons for it back in the days before cooperative  
multitasking, but for the most part MDI itself was deprecated for  
very good, solid reasons.

Catch me on Jabber some time and I'm sure I'll be able to discuss my  
viewpoint in more detail.   :-)

On Mon, 26 Mar 2007 14:07:49 -0400
"bulia byak" <buliabyak@...> wrote:

> On 3/26/07, Gustav Broberg <broberg@...>
> wrote:
> > The patch adds a dockable pane to the desktop on which any
> > GTKmm:ified dialog can be docked. Here are some screenshots showing
> > what it's all about:
> > http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> > http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
> 
> This is an extremely desirable change. It turns Inkscape from a clunky
> and messy Gimp lookalike into a clean, modern-looking application. I'm
> all for it.
> 
> However, I foresee one problem. Currently all of our dialogs are built
> around the "one dialog serves all open windows" concept. Making them
> dock to the editing window seems to switch them to the "each window
> has its own dialog" paradigm. This therefore may not be as
> straightforward, because in each dialog we will also need to find and
> fix code which (1) assumes there's always only one copy of the dialog
> and (2) switches its state and display when a new window gets focus,
> and (3) applies the changes in dialog to the currently active window.
> 
> Gustav, have you looked into these problems at all? I suspect the
> severity of the required changes varies from dialog to dialog, but at
> least for Fill&Stroke it's going to be rather major (although it
> hasn't even been ported to GTKmm and Dialog class yet, as are many
> other dialogs).

No, I haven't, so you're right that it's still a problem to solve.

Skipping support for the current floating style dialogs would make this
easier to solve but then gdl would be a requirement. There would still
be the problem with gdl's floating dialogs, as Bryce mentioned, though.
However, I'm not sure that I think it's necessary to keep the singleton
behavior for them...

I like the single desktop approach with multiple (tabbed) documents that
you suggest. With gdl it wouldn't be a problem to allow documents to be
arranged side by side in a split view, or as tabs in a notebook.

On the other hand I guess that some people just like their windows to be
managed by their window manager :)

--
Gustav

On Mon, Mar 26, 2007 at 02:25:29PM -0400, bulia byak wrote:
> 
> By the way, one way to resolve this issue would be to go even further
> in UI redesign and abandon separate windows altogether, instead adding
> tabs to the main interface for open documents. I personally would
> welcome this, although I'm afraid there are many who are used to the
> current behavior (e.g. for viewing documents or views of the same
> document side by side).

With GIMP and Inkscape, I like to put dialogs on the side of the screen 
and allow them to fall back behind the document window. As I use focus 
follows mouse and auto-raise without delay, I can bring any dialog to 
the front with a flick of the mouse and the document back up as easily.
This is especially useful with GIMP and large images.

Of course, this is all far away from the defaults, so few people can be 
expected to do the same. However, there's the related idea of having 
auto-expanding/collapsing side panels.

Floating dialogs that stay on top are only good for obstructing the 
view and getting in the way.

I wouldn't mind document tabs, but there needs to be a way to have 
documents side by side for comparison. Vertically or Horizontally 
split views, please :)

-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil

Alexandre Prokoudine wrote:
> On 3/26/07, bulia byak wrote:
> 
>> By the way, one way to resolve this issue would be to go even further
>> in UI redesign and abandon separate windows altogether, instead adding
>> tabs to the main interface for open documents.
> 
> And how do you see mulltiple pages GUI implemented then?

What about how Scribus handles multiple pages? Or Acrobat which is a 
different method (and less appealing to me personally).

-Josh

On 3/26/07, bulia byak wrote:

> By the way, one way to resolve this issue would be to go even further
> in UI redesign and abandon separate windows altogether, instead adding
> tabs to the main interface for open documents.

And how do you see mulltiple pages GUI implemented then?

Alexandre

bulia byak wrote:
> I'm afraid there are many who are used to the
> current behavior (e.g. for viewing documents or views of the same
> document side by side).
Personally I have always preferred the model where there is one 
encompassing program window, and then sub windows contained within it.  
I can't stand millions of separate windows (i.e. GIMP).  The taskbar 
only shows one item for the program instead of one for each document 
open.  If the tabs you are talking about could be "minimized" (using the 
term loosely) you could achieve the side-by-side behavior.

Here is a screen shot showing what I mean:
http://gbanaszk.oasis.nexus.carleton.ca/SummerOfCode/docsSideBySide.png

Just something to keep in the back of your mind...

As a side note, I am highly in favor of docking things.  The reason is 
the same as why I like the model mentioned above: I like things to be 
organized and organizable! I hope you can get dockers working well for 
all OS's without too much hassle.

Gail

On Mon, Mar 26, 2007 at 02:25:29PM -0400, bulia byak wrote:
> By the way, one way to resolve this issue would be to go even further
> in UI redesign and abandon separate windows altogether, instead adding
> tabs to the main interface for open documents. I personally would
> welcome this, although I'm afraid there are many who are used to the
> current behavior (e.g. for viewing documents or views of the same
> document side by side).

I'm fairly certain that abandoning separate windows would meet with a
great deal of criticism.  Recalling some of the SDI/MDI debates from
early on the project I'm fairly certain there are strong feelings on
this topic.  ;-)

Bryce

On Mon, 26 Mar 2007 21:51:46 +0400
"Alexandre Prokoudine"
<alexandre.prokoudine@...> wrote:

> On 3/26/07, Gustav Broberg wrote:
> > Hi all,
> >
> > I've been busy with work since the release of 0.45, but now I have
> > finally found some time to spend on Inkscape again... :)
> >
> > I have uploaded a patch to the tracker which is a first attempt to
> > implement dockable dialogs/panels using gdl (Gnome development
> > library).
> 
> It looks cool, but fals building on current SVN with gdl 0.6.1:
> 
> [...]

Hmm, turns out gdl.h doesn't include everything needed prior to 0.7
(probably because the dockbar which holds iconified dock items wasn't
considered stable :/). I've uploaded a new version to the tracker which
should compile.

--
Gustav

Bulia byak wrote:
> > On 3/26/07, Gustav Broberg <broberg@...> wrote:
> > The patch adds a dockable pane to the desktop on which any=20
> GTKmm:ified=20
> > dialog can be docked. Here are some screenshots showing=20
> what it's all
> > about:
> > http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> > http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
>=20
> This is an extremely desirable change. It turns Inkscape from=20
> a clunky and messy Gimp lookalike into a clean,=20
> modern-looking application. I'm all for it.

Loving it!

> (although it hasn't even been ported to GTKmm and=20
> Dialog class yet, as are many other dialogs).

As this is already an ongoing effort, this should not hold it back.=20
Maybe we should bump this effort on the prio list?

Regards,
Johan

On 3/26/07, bulia byak <buliabyak@...> wrote:
> However, I foresee one problem. Currently all of our dialogs are built
> around the "one dialog serves all open windows" concept. Making them
> dock to the editing window seems to switch them to the "each window
> has its own dialog" paradigm. This therefore may not be as
> straightforward, because in each dialog we will also need to find and
> fix code which (1) assumes there's always only one copy of the dialog
> and (2) switches its state and display when a new window gets focus,
> and (3) applies the changes in dialog to the currently active window.

By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents. I personally would
welcome this, although I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On Mon, Mar 26, 2007 at 02:07:49PM -0400, bulia byak wrote:
> On 3/26/07, Gustav Broberg <broberg@...> wrote:
> > The patch adds a dockable pane to the desktop on which any GTKmm:ified
> > dialog can be docked. Here are some screenshots showing what it's all
> > about:
> > http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> > http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
> 
> This is an extremely desirable change. It turns Inkscape from a clunky
> and messy Gimp lookalike into a clean, modern-looking application. I'm
> all for it.
> 
> However, I foresee one problem. Currently all of our dialogs are built
> around the "one dialog serves all open windows" concept. Making them
> dock to the editing window seems to switch them to the "each window
> has its own dialog" paradigm. This therefore may not be as
> straightforward, because in each dialog we will also need to find and
> fix code which (1) assumes there's always only one copy of the dialog
> and (2) switches its state and display when a new window gets focus,
> and (3) applies the changes in dialog to the currently active window.

I think this may not be a showstopper.  Currently, the dialogs use the
ACTIVE_DOCUMENT macro or similar to get the currently active document,
and adjust themselves accordingly.

But for the gtkmm'd dialogs, it would be straightforward to refactor
them to use a routine in the dialog manager to get the document (and/or
desktop) instead.  The dialog manager is currently treated as a
singleton, but I think it should not be difficult to switch it to be
attached to a specific desktop/document.

Where things could get tricky is if the user docks some dialogs but
leaves others undocked.  Perhaps there should be a global dialog
manager, plus ones that are attached to specific desktops.  Sorting out
the message handling could be a bit tricky, but not overly so.

Bryce

On Mon, Mar 26, 2007 at 07:20:49PM +0200, Gustav Broberg wrote:
> I have uploaded a patch to the tracker which is a first attempt to
> implement dockable dialogs/panels using gdl (Gnome development
> library).
> 
> The patch adds a dockable pane to the desktop on which any GTKmm:ified
> dialog can be docked. Here are some screenshots showing what it's all
> about:
> http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png

Very cool, this definitely looks like something we want.

> To compile you'll need gdl >= 0.6.1, the latest version is available
> here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2
> 
> Gdl is a fairly small UI library developed for IDE:s such as
> Anjuta. The main thing it provides is a set of components to build
> dockable interfaces.
> 
> I realize that it would be better to do this without an additional
> library, but right now I think gdl is the best option assuming that we
> want a dockable interface.

If it works as a reasonably standalone library, with dependencies only
on libraries we already depend on (gtkmm, glib, etc.) then this is
probably a good choice.  If it depends on libraries we don't already
have in the codebase, then that could be a problem, as it increases our
"weight" on windows, non-GNOME platforms, and so on.

This could be made optional in autoconf, as we do with inkboard, etc. 
However, this feature is something that probably should be implemented
in a way that allows us to use it universally.

Can you please investigate the dependent libraries, and especially look
for ways to "trim" the dependencies down?  The nautilus dependency is
especially worrisome.

> The pros of using gdl, as I see it, are:

Thanks, this is a good analysis.

Bryce

On 3/26/07, Gustav Broberg <broberg@...> wrote:
> The patch adds a dockable pane to the desktop on which any GTKmm:ified
> dialog can be docked. Here are some screenshots showing what it's all
> about:
> http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png

This is an extremely desirable change. It turns Inkscape from a clunky
and messy Gimp lookalike into a clean, modern-looking application. I'm
all for it.

However, I foresee one problem. Currently all of our dialogs are built
around the "one dialog serves all open windows" concept. Making them
dock to the editing window seems to switch them to the "each window
has its own dialog" paradigm. This therefore may not be as
straightforward, because in each dialog we will also need to find and
fix code which (1) assumes there's always only one copy of the dialog
and (2) switches its state and display when a new window gets focus,
and (3) applies the changes in dialog to the currently active window.

Gustav, have you looked into these problems at all? I suspect the
severity of the required changes varies from dialog to dialog, but at
least for Fill&Stroke it's going to be rather major (although it
hasn't even been ported to GTKmm and Dialog class yet, as are many
other dialogs).

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On 3/26/07, Alexandre Prokoudine wrote:

> Previously we discussed using CurlyAnkles for docking, which means far
> less dependencies.

Forget this part of email, please :)

Alexandre

On 3/26/07, Gustav Broberg wrote:
> Hi all,
>
> I've been busy with work since the release of 0.45, but now I have
> finally found some time to spend on Inkscape again... :)
>
> I have uploaded a patch to the tracker which is a first attempt to
> implement dockable dialogs/panels using gdl (Gnome development
> library).

It looks cool, but fals building on current SVN with gdl 0.6.1:

./cxxtest    -Wall -Wformat-security -W -Wpointer-arith -Wcast-align
-Wsign-compare -Woverloaded-virtual -Wswitch -D_FORTIFY_SOURCE=2
-Wno-unused-parameter -g -O2 -MT application/editor.o -MD -MP -MF
"application/.deps/editor.Tpo" \
          -c -o application/editor.o `test -f 'application/editor.cpp'
|| echo './'`application/editor.cpp; \
        then mv -f "application/.deps/editor.Tpo"
"application/.deps/editor.Po"; \
        else rm -f "application/.deps/editor.Tpo"; exit 1; \
        fi
./ui/widget/dock.h:51: error: ISO C++ forbids declaration of
'GdlDockBar' with no type
./ui/widget/dock.h:51: error: expected ';' before '*' token

Previously we discussed using CurlyAnkles for docking, which means far
less dependencies.

http://curlyankles.sourceforge.net/widgets_docking.html

Did you have a chance looking at it?

Alexandre

On 2007-March-26  , at 19:20 , Gustav Broberg wrote:
> I have uploaded a patch to the tracker which is a first attempt to
> implement dockable dialogs/panels using gdl (Gnome development
> library).
> [...]
> The patch adds a dockable pane to the desktop on which any GTKmm:ified
> dialog can be docked. Here are some screenshots showing what it's all
> about:
> http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
> http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png

I love it!

> To compile you'll need gdl >= 0.6.1, the latest version is available
> here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2
[...]
>  * I haven't tried it on win32 or Mac OS X, so I'm not sure about the
>    compatibility. It used to require some gnome only libraries, but it
>    doesn't anymore from what I know.

gdl 0.7.2 is available on Mac OS X via DarwinPorts so it should not  
be a problem to get it. On the other hand, it still requires many  
gnome packages to be installed (gnome-session, gnome-desktop,  
nautilus, metacity, evolution-data-server etc.). Basically it  
requires to install the whole gnome desktop and it may be a bit  
overkill just to have dockable windows... too bad.

JiHO
---
http://jo.irisson.free.fr/

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (24)	Nov (524)	Dec (655)
2004	Jan (515)	Feb (624)	Mar (407)	Apr (593)	May (422)	Jun (529)	Jul (737)	Aug (448)	Sep (343)	Oct (503)	Nov (593)	Dec (474)
2005	Jan (771)	Feb (602)	Mar (588)	Apr (488)	May (218)	Jun (544)	Jul (889)	Aug (657)	Sep (781)	Oct (486)	Nov (750)	Dec (409)
2006	Jan (442)	Feb (242)	Mar (303)	Apr (617)	May (811)	Jun (525)	Jul (367)	Aug (318)	Sep (202)	Oct (395)	Nov (260)	Dec (185)
2007	Jan (525)	Feb (554)	Mar (494)	Apr (344)	May (168)	Jun (295)	Jul (459)	Aug (468)	Sep (390)	Oct (558)	Nov (351)	Dec (487)
2008	Jan (583)	Feb (471)	Mar (979)	Apr (436)	May (335)	Jun (368)	Jul (281)	Aug (239)	Sep (243)	Oct (338)	Nov (248)	Dec (149)
2009	Jan (465)	Feb (349)	Mar (388)	Apr (415)	May (211)	Jun (226)	Jul (262)	Aug (376)	Sep (419)	Oct (370)	Nov (257)	Dec (449)
2010	Jan (377)	Feb (268)	Mar (345)	Apr (281)	May (73)	Jun (192)	Jul (336)	Aug (201)	Sep (328)	Oct (131)	Nov (162)	Dec (248)
2011	Jan (138)	Feb (182)	Mar (241)	Apr (174)	May (64)	Jun (321)	Jul (220)	Aug (139)	Sep (214)	Oct (174)	Nov (91)	Dec (119)
2012	Jan (182)	Feb (260)	Mar (207)	Apr (119)	May (118)	Jun (150)	Jul (72)	Aug (125)	Sep (137)	Oct (187)	Nov (122)	Dec (131)
2013	Jan (151)	Feb (128)	Mar (290)	Apr (236)	May (157)	Jun (204)	Jul (266)	Aug (190)	Sep (476)	Oct (257)	Nov (193)	Dec (225)
2014	Jan (228)	Feb (189)	Mar (372)	Apr (340)	May (272)	Jun (191)	Jul (138)	Aug (182)	Sep (204)	Oct (283)	Nov (271)	Dec (168)
2015	Jan (154)	Feb (217)	Mar (182)	Apr (198)	May (227)	Jun (91)	Jul (64)	Aug (138)	Sep (175)	Oct (133)	Nov (83)	Dec (128)
2016	Jan (198)	Feb (240)	Mar (411)	Apr (213)	May (285)	Jun (211)	Jul (88)	Aug (83)	Sep (69)	Oct (210)	Nov (296)	Dec (136)
2017	Jan (303)	Feb (273)	Mar (218)	Apr (149)	May (199)	Jun (486)	Jul (237)	Aug (219)	Sep (188)	Oct (113)	Nov (72)	Dec (76)
2018	Jan (146)	Feb (113)	Mar (189)	Apr (69)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

S	M	T	W	T	F	S
				1 (26)	2 (12)	3 (7)
4 (11)	5 (10)	6 (8)	7 (7)	8 (16)	9 (4)	10 (6)
11 (7)	12 (23)	13 (20)	14 (7)	15 (3)	16 (19)	17 (6)
18 (3)	19 (12)	20 (23)	21 (12)	22 (15)	23 (22)	24 (27)
25 (22)	26 (42)	27 (18)	28 (48)	29 (26)	30 (23)	31 (9)

Thanks for helping keep SourceForge clean.

Inkscape

Brought to you by: bryce, buliabyak, doctormo, joncruz, scislac

inkscape-devel — Development list for Inkscape