- Inkscape Devel - Inkscape Mailman

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

Re: Sodipodi flags collection
by Christian Schaller 15 Nov '03

15 Nov '03

Hi Dirk, I am sending this mail to the sodipodi and inkscape lists as I think the people there can both better reply than me and are also the people most able to look at the import code you are pointing to. I hope to see this code or a derrative of it enter sodipodi or inkscape giving us EPS/Postscript import as it is something I really miss. Christian On Sat, 2003-11-15 at 12:38, Dirk Sch��nberger wrote: > > Hi Dirk, > > Well our problem is that Sodipodi doesn't currently support importing > > EPS images. I am also a bit worried about copyright issues with your > > flags since you say they come from a variety of sources. > > > But thanks for the offer :) > > > Christian > > No problem about the images. > > Do you have a import framework at hand for Sodipodi? > I have done some data conversion work for Postscript related file formats, > namely Adobe Illustrator (AI). > Version 1 is implemented in C++, you can find it the KDE CVS, module > koffice/import/karbon/ai (or somesuch) > Combined with ghostscript's ps2ai filter it should be possible to do > importing generic EPS files. > > Version 2 is currently only a prototype implemented in Ruby. It provides a > SAX like API to Adobe Illustrator files, which I think makes using the > filter in applications easier. > The filter is again in KDE CVS, module kdenonbeta/opal/import/ai (or > somesuch). > > Currently I have no target format besides XML where I can see the results of > my importer, so I kind of stopped working on it. > > Regards > Dirk > > > > > >

1 0

Re: [Inkscape-cvs] inkscape/src/dialogs
by T Ingham 15 Nov '03

15 Nov '03

I just wanted to share in a moment of bliss. I absolutely love it when I see bulia byak in the "From" column. -thomas On Nov 15, 2003, at 5:00 AM, bulia byak wrote: > Update of /cvsroot/inkscape/inkscape/src/dialogs > In directory sc8-pr-cvs1:/tmp/cvs-serv29274/src/dialogs > > Modified Files: > object-properties.c > Log Message: > fixed window title > > > ------------------------------------------------------- > 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-cvs mailing list > Inkscape-cvs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-cvs >

1 0

Re: [Sodipodi-list] Sodipodi SVG flags 1.0
by Bryce Harrington 15 Nov '03

15 Nov '03

On Thu, 13 Nov 2003, Christian Schaller wrote: > Sodipodi flags 1.0 > > This is the first release of the Sodipodi flag collection. This > collection currently consist of over 210 different international and > local flags. The flags are donated by their authors into the public > domain. The flags are in the scalable and free SVG format which today > is supported by most major vector graphics programs. > > The assembly of this huge collection has been made possible thanks to > the hard work of many people. We big thank you goes to all our > contributors listed in the CREDITS file distributed with this package. > We would especially like to thank Tobias Jacobs, Sigge Kotliar, Cezary > Biel, Brett Roper, Daniel McRae and Lauris Kaplinski, whose > contributions count for around half the collection. Congratulations and thank you to all who have made this possible. Having a complete collection of SVG flags in the public domain will be of great benefit to SVG and to the technical world in general. This project is also proving to be an excellent example of the power of the open source development model in action. Keep up the great work everyone! Bryce

1 0

Re: [Inkscape-devel] CVS help
by herve couvelard 14 Nov '03

14 Nov '03

> cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co > inkscape > > That will put the data in your local directory (so make sure you're > where you want the data when you run the command). > > --Ted > that was it.. simple in fact when someone knows :-) thanks hervé

1 0

CVS help
by herve couvelard 14 Nov '03

14 Nov '03

Hello.. Could someone be very helpfull and give the command (linux's one ) to use cvs . I think it is soething like this : EXPORT CVS root cvs -Z3 (??) .......... because i can't find the way to do it eaysily and as i am not a anciant user of nux.... i would appreciate a way to do it without downloading the complete code... thanks Hervé

5 6

[Fwd: Sodipodi SVG flags 1.0]
by Ted Gould 14 Nov '03

14 Nov '03

This might be of interest to Inkscape folks too! Plus we even got a mention. --Ted -----Forwarded Message----- > From: Christian Schaller <uraeus@...55...> > Subject: Sodipodi SVG flags 1.0 > Date: 13 Nov 2003 21:03:36 +0100 > > Sodipodi flags 1.0 > > This is the first release of the Sodipodi flag collection. This > collection currently consist of over 210 different international and > local flags. The flags are donated by their authors into the public > domain. The flags are in the scalable and free SVG format which today > is supported by most major vector graphics programs. Most flags are done > using the Sodipodi vector drawing application. In others words these are > free flags in a free format made with a free application. > > The core collection of flags in this collection are meant to be as > accurate as possible. If you discover flags in here that have wrong > proportions or wrong colors then please update the flag with the correct > colors or sizes and send it to us with an explanation. > > New flags are of course also welcomed, but remember we need a clear > statement from you that you dedicate the flag to the public domain, > preferably using the Creative Commons public domain dedication process > found here: > http://creativecommons.org/license/publicdomain-2 > We do hope that many of you take some time to help us make this an even > more complete collection. > > We hope that this collection can be useful to people in many different > settings be that in relation to software, publishing, education and so > on. > > The assembly of this huge collection has been made possible thanks to > the hard work of many people. We big thank you goes to all our > contributors listed in the CREDITS file distributed with this package. > We would especially like to thank Tobias Jacobs, Sigge Kotliar, Cezary > Biel, Brett Roper, Daniel McRae and Lauris Kaplinski, whose > contributions count for around half the collection. > > You can see all of the currently contributed flags here: > http://www.sodipodi.com/index.php3?section=clipart/flags > > The creation of these flags had not been possible without the hard work > that free software coders have put into great tools like Sodipodi and > librsvg. The projects have helped increase the viability of SVG in free > and open source software a lot. > > Both these two tools and the new Inkscape project do need more coders in > order to improve further. For instance you will notice that many of the > SVG flags do not render correctly in Nautilus due to some problems with > librsvg. People interested in working on these and other issues are > highly encouraged to join the project mailing-lists. You find the > projects here: > http://www.sodipodi.org > http://librsvg.sf.net > http://www.inkscape.org > > > You can download the package in either tar.gz or zip format from the > sourceforge file area: > http://prdownloads.sourceforge.net/sodipodi/sodipodi-flags-1.0.tar.gz?downl… > http://prdownloads.sourceforge.net/sodipodi/sodipodi-flags-1.0.zip?download > > Sincerely, > Christian Schaller > > _______________________________________________ > gnome-announce-list mailing list > gnome-announce-list@...45... > http://mail.gnome.org/mailman/listinfo/gnome-announce-list >

1 0

Re: Bug: Number type warning in help.c
by Robert Crosbie 14 Nov '03

14 Nov '03

Ok, so I turned off digest mode. In the mean time, excuse the cut and paste below: This patch doesn't really fix the problem, it only masks the compiler warning. If gtk_window_set_default_size is expecting gints, then sp_document_width should return a gint instead of a gdouble and the document structure should store its width and height as gint. I don't have the source accessible to me right now, so I can't see how it is defined. If a width was defined that exceeded INT_MAX, then when the gdouble was cast to a gint, data would be lost. A user would see a windo much smaller than they exected being displayed. Now, the other way round is fine, you can cast away if you're going from a gint TO a gdouble. Rob, From: Jon A. Cruz <jon@...51...> Bug: Number type warning in help.c 2003-11-12 10:01 Here's a patch for bug [ 840545 ] Number type warning in help.c Turns out that it was a very simple case. Now I'm onto bugs 840539 and 840543 Oh, and I've dusted off my Sourceforge user ID of joncruz Index: help.c =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/help.c,v retrieving revision 1.2 diff -u -r1.2 help.c --- help.c 30 Oct 2003 05:52:06 -0000 1.2 +++ help.c 12 Nov 2003 17:45:34 -0000 @@ -47,7 +47,7 @@ w = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_set_title (GTK_WINDOW (w), _("About inkscape")); - gtk_window_set_default_size (GTK_WINDOW (w), sp_document_width (doc), sp_document_height (doc)); + gtk_window_set_default_size (GTK_WINDOW (w), (gint)(sp_document_width(doc)), (gint)(sp_document_height(doc)) ); #if 1 gtk_window_set_policy (GTK_WINDOW (w), TRUE, TRUE, FALSE); #endif Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 2

keys, unsinkability
by bulia byak 14 Nov '03

14 Nov '03

I've collected shortcut suggestions from recent discussions; please see the top of TODO on the KeyboardShortcuts wiki and comment/add as appropriate. There's also a new proposal on keys for editing control points in node editor. Has anyone tested the unsinkable dialogs (toolbox and ctrl-shift-f)? Use the UnsinkableDialogs page to report. -- __________________________________________________________ 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