- Inkscape Devel - Inkscape Mailman

indent options
by Robert Crosbie 16 Nov '03

16 Nov '03

I was just wondering what indenting convention we were using for inkscape. If I had some new code to submit, what indent command should I run on it to make sure it looks like all the other code? Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

preferences broken?
by bulia byak 16 Nov '03

16 Nov '03

Maybe it's just me, but the .inkscape/preferences file is never saved. On my machine it is dated Nov 13; since then, nobody touched it. I figured that it's because the inkscape_dispose function is not run upon exit. Where is it supposed to be called? I tried this: void inkscape_exit (Inkscape *inkscape) { g_object_run_dispose (inkscape); // added gtk_main_quit (); } but this resulted in lots of failed asserts, so it's perhaps the wrong place. Someone please fix this! -- __________________________________________________________ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup Search Smarter - get the new eXact Search Bar for free! http://www.exactsearchbar.com/

1 0

[PATCH] trivial: renamed "desactivate" to "deactivate"
by Kees Cook 16 Nov '03

16 Nov '03

Trivial patch attached... -- Kees Cook @outflux.net

1 0

[PATCH] fix for GDK_SCROLL event blindness
by Kees Cook 16 Nov '03

16 Nov '03

Attached is the fix for mouse wheel support. This is against anon CVS, and I know you just did a big code merge, so hopefully this will be easy to apply since it's so small. :) -- Kees Cook @outflux.net

1 1

[Inkscape-wiki] The DevelopmentRoadmap page at Wiki has been changed. (fwd)
by Bryce Harrington 16 Nov '03

16 Nov '03

I've added a new mailing list for tracking changes to the wiki. The emails you get look like the one below. The emails are sent only when the wiki author checks the "Send to mailing list" checkbox, so this list should be fairly light traffic. To subscribe to this or other lists, go here: http://www.inkscape.org/mailing_lists.php Bryce P.S. The inkscape-cvs@ list is great for keeping an eye on what everyone's working on. ---------- Forwarded message ---------- Date: Sat, 15 Nov 2003 16:03:28 -0800 From: InkscapeWiki@...58... Reply-To: bryce@...1..., tingham@...59..., tvon@...60..., rick@...61..., inkscape-wiki(a)lists.sourceforge.net To: bryce@...1..., tingham@...59..., tvon@...60..., rick@...61..., inkscape-wiki(a)lists.sourceforge.net Subject: [Inkscape-wiki] The DevelopmentRoadmap page at Wiki has been changed. The Wiki page DevelopmentRoadmap at http://www.inkscape.org/cgi-bin/wiki.pl?DevelopmentRoadmap has been changed by Bryce to revision 73. (Replying to this notification will send email to the entire mailing list, so only do that if you mean to. To remove yourself from this list, visit http://www.inkscape.org/cgi-bin/wiki.pl?action=editprefs .) ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Inkscape-wiki mailing list Inkscape-wiki(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-wiki

1 0

Project Status
by Bryce Harrington 15 Nov '03

15 Nov '03

Project Status - November 15, 2003 ---------------------------------- Activity and progress with the project over the past two weeks has been far beyond expectations. Inkscape 0.35 has been completed and released. We've redesigned and fleshed out the website (and wiki) considerably. Our activity rating on SourceForge hit the upper 99th percentile. And numerous developers have contributed new features, bug fixes, and experimental prototypes and mockups. Further, we've established our project identity and are forming into a friendly development-focused community. Now that the release is out, we will be applying our focus to implementation of some new features. We wish to do this before heading forth into major architectural changes so that we have a solid release with new capabilities to offer users in the near term. Statistics Nov 02 Nov 15 ========== ====== ====== Lifetime Rank on SourceForge: 6103 4391 (56.2%) (68.5%) Week's Rank on SourceForge: 6023 62 (56.8%) (99.6%) Lines of Code in src/: 115,754 115,901 Lines of Docs in doc/: 1,135 1,135 Lines of content in website: 74 1,173 Size of the Inkscape wiki: 0 3,700 Days since last ChangeLog mod: 4 0 Bugs open/total: 0/0 9/15 Features open/total: 0/0 18/18 Patches open/total: 0/0 1/ 6 CVS Commits (as per inkscape-cvs): 148 481 Inkscape-devel membership: 4 49 Inkscape-announce membership: 0 9

1 0

Milestone 2
by Bryce Harrington 15 Nov '03

15 Nov '03

Here's the tasks for Milestone 2, which will correspond to the Inkscape 0.36 release. http://www.inkscape.org/cgi-bin/wiki.pl?DevelopmentRoadmap The focus of this milestone is on implementing new features. I've tried to capture what folks are working on but if I've missed something please update the Wiki or reply to this email. In particular I wasn't sure what to list for Bulia Byak and Robert Crosbie. There are also a few important tasks that we don't have a developer for. If you can volunteer for the task please let me know or add your name to the task in Wiki. === Milestone 2 === Objective: Implement new features & do prep work for major changes in future Inkscape Production: * (DONE) Create Freshmeat project for Inkscape [tgould] * (DONE) Remove the KDE / Qt code and dependencies [manny] * Check all listed Sodipodi bugs and copy recreatible ones to Inkscape's CVS tracker * Copy open patches from Sodipodi patch tracker to Inkscape * Add modelines to source files for popular editors (vim/emacs) [tvon] * Implement preliminary support for doxygen or doc++ in the codebase [joncruz] * Implement preliminary support for arrowheads on path ends [bryce] * Implement preliminary support for layers [mental] * Implement preliminary support for iso & hex grid [njh] * Eliminate all warnings in g++ build process on Linux [joncruz] * Release 0.36 and post to Freshmeat [tgould] * Create RPM for 0.36 [bryce] * Create Deb for 0.36 * Create Window exe package for 0.36 Inkscape Experimental R&D * Identify the remaining XML compliance bugs needing to be fixed & add to plan for M3/M4 [mental] * (DONE) Describe what needs to be done to fix ambiguous default namespace issue [mental] * Select a regression test system strategy (cutest?) [mental] * Build a prototype grid options dialog using gtkmm [njh] * Prototype stroking/path enhancements [njh] * Create list of requirements for plugin system & gain team concensus on it [joncruz, bryce] Inkscape Website & Project * (DONE) Convert wiki to new look and feel [tvon] * Convert website to new look and feel [tvon] * Post project status [bryce] * See if it's possible to make wiki send edit notification to a mailing list & set it up if so [bryce] * Figure out why http://www.inkscape.org/mockups/export_dialog_02.png doesn't display [tvon] * Plan out Milestone 3 [bryce]

1 0

Milestone 1 achieved
by Bryce Harrington 15 Nov '03

15 Nov '03

The tasks for Milestone 1 are completed. === Milestone 1 === Inkscape Production * (DONE) Get inkscape to build with a C++ compiler [team] * (DONE) Fix CDATA issue [mental] * (DONE) Get codebase to successfully complete `make distcheck` -- mental says 'worksforme' [team] * (DONE) Fix 'snap to guides' crash bug [bryce] * (DONE) Update the about dialog to include the new logo and version [bryce, tvon] * (DONE) Cut a release of Inkscape 0.35 [ted] * (DONE) Upload release tarball of Inkscape 0.35 to Inkscape SF file manager [ted] Inkscape Experimental * (DONE) Initiate work on grid-proto code & put in CVS [njh] * (DONE) Conceptualize a new export dialog in python [tvon, njh] Inkscape Website & Project * (DONE) Create logo for Inkscape [team] * (DONE) Create look and feel graphical design prototype for website [tvon] * (DONE) Create 3+ screenshots of Inkscape Production [bryce] * (DONE) Flesh out website more fully [bryce] * (DONE) SourceForge RFE section needs setting up (categories and groups) [bryce] * (DONE) Create inkscape_project module & add wiki.pl there [bryce]

1 0

New tracker categories
by Bryce Harrington 15 Nov '03

15 Nov '03

I've added the following categories in each of the trackers: Other UI Node Editing Shape Editing Printing Saving Exporting Color Transformations Build

1 0

Escaping Dialogs
by T Ingham 15 Nov '03

15 Nov '03

Hello all, Nate suggested that it might be a good idea for me to vocalize my thoughts on a particular recent patch to Ink. I don't think that this is a bad patch at all, as it demonstrates how quickly we can change the behavior of this application, and integrate it with the source base. Not only that but it is a perfect example of how the dev plan works. Patch now, talk later. So that's what I'm here to do, in reference to the patch which applies the Escape key event to hiding the currently selected dialog. The points I am taking issue with stem from both my years of experience using Adobe Illustrator, as well as being a thoughtful user of all manner of software applications. While I don't have any reference handy to any sort of HIG on this behavior, I'm sure you'll take me on my word that using the Escape key in this manner is a "bad thing". Here's why: #1. Intended behavior. When I am editing a value in a dialog, and I type the wrong value into a text field, I would immediately think "Escape that command" or "Revert" this results in me hitting the Escape key, where I expect that I can then type in the appropriate value into the text field. Instead, Inkscape will kindly void my transaction and hide the input mechanism. This results in me having to open the dialog again, and enter the new value. Instead of hiding the dialog, I believe that the event tree should happen in this order: - Revert any currently focused field to it's previous value. - If no fields are currently focused, send the main focus of the application to the Canvas window. This will leave the dialog in it's current position, ( which is only a problem until we figure out how to root these dialogs in a constant location ) and perform the Escape routine as expected. #2. Spatiality When aiming to provide users with a consistent and workflow-friendly interface, it is of the utmost importance that we allow the user to decide what is placed where, and when. This means that palettes really should respond to meta-keys at all ( save for undo and enter for application of current edit ) The dialogs in Inkscape are non-modal, and therefore closing them is not a trivial thing. It is forseeable that in the future, a dialog such as the Object Properties window will remain open for the duration of a work cycle. It would be used to monitor a drag operation for placement of a shape in the current document, as well as other utilities. When dialogs become not only mechanisms to edit information, but also to view information, the location on the screen simply *must* be maintained. Dialogs that move and disappear are of only moderate usefulness. #3. Alternatives In Illustrator, you can hide all dialogs by hitting "Tab", this provides you with a quick device for previewing your work without interface clutter, or maximizing your work area regardless of tool panels. Tab again will show the dialogs that were hidden in the last operation. I propose that we implement this with one addition: Shift+Tab, or Shift+~ would be used for closing the currently selected ( focused ) dialog. While I don't believe that users will often want to close dialogs such as Object Style, or Properties, there are some dialogs which operate in a near modal fashion: Transformation ( which could be seen as a single cycle operation ) "Open Transformation Dialog"->"Apply Transformation"->"Close Transformation Dialog" however these sorts of operations should be grouped together. Perhaps we could spend some time identifying which palettes would most likely remain open, and which would be single cycle operations, group them together, and apply different UI characteristics for each group. If those key commands are reserved, I'm sure we could find an equally appropriate set of actions to assign to this process. I don't think it's without cause that the patch was applied, however I do think that we should be aiming at producing dialogs which the user will keep open and assign locations to. This is the sort of thing that increases productivity with any application, without much effort from the user. I believe that the term Dialog is being misused here, and perhaps that is where most of the problem is coming from. To be effective, we should class out the windows that should be palettes apart from the dialogs. We could then provide some form of modality for the dialogs that are left, and windows would behave differently depending on what was to be done. I welcome any further discussion on this, as I could be totally off-base with the entire thing. I guess we really wouldn't know until we could see it implemented both ways and by then all the work would be done. Thanks for your time and patience, -Thomas

3 8