- Inkscape Devel - Inkscape Mailman

Re: Menu layout feedback [Re: [Inkscape-devel] Snap to grid]
by bulia byak 29 Nov '03

29 Nov '03

> I'd be prepared to write a few simple introductory pages to get things > started, explaining Vector versus Raster graphics for one thing. But that one is already written by me :) Thanks for reminding me, I just put it up on Wiki (replacng Sodipodi by Inkscape - it was written for Inkscape originally). Feel free to edit, or add more documentation :) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Object and XML trees
by MenTaLguY 29 Nov '03

29 Nov '03

Just a quick note ... I think tomorrow (or later today, after I get up, depending on your timezone) I will start work on an object ("layers") view, and a reworked XML view. The plan is to have both of the new views derive from SPView and their corresponding widgets derive from SPViewWidget. -mental

1 0

ANNOUNCE: New Scribus Website
by Peter Linnell 29 Nov '03

29 Nov '03

Hi all, I wanted to announce a complete redesign of the Scribus website. Many thanks to Craig Bradney for helping set this up and nurturing my newbie php skills. We still have a few tweaks to make, but its up and running. www.scribus.net or www.scribus.org.uk There is also a nice surprise waiting on the front page... Scribus complements Inkscape by importing most Inkscape created SVG when saved as "plain SVG" and exporting it to print, PDF or EPS. Scribus also supports CUPS directly for enhanced printing support including the CUPS-Gimp-Print Drivers. Enjoy, Peter

1 0

Re: [Inkscape-devel] saving files
by Robert Crosbie 28 Nov '03

28 Nov '03

>On Thu, 2003-11-27 at 19:29, Robert Crosbie wrote: > > I have fixed the problem with the save dialog dropping back a directory >each > > time you "Save as", but it seems the system module is not saving the the > > docname, docbase and a lot of other attributes to the file. This means >that > > inkscape keeps prompting you for the file name to save as every time you > > save. > >The problem appears to be that the first time a file is saved, the "pure >SVG" output module is being used instead of the "SVG with extensions" >module (meaning no inkscape: or sodipodi: attributes are saved). > >I'm not sure why this is yet... it's causing all sorts of problems. > >Ted, any insights? > >-mental Yeah, I figured this out after my last post. Perhaps, even in "pure SVG" mode we could still store some important attributes, like docname and modified. Do we really need docbase? Couldn't it be determined from docname? docname always seems to have the complete path for me. I'm a big fan of having minimal, clean svg. Cheers, Rob. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] DOM SVG Canvas
by Ian Grant 28 Nov '03

28 Nov '03

> Yes Inkscape does have such an internal structure. A few months ago > Mental had begun work on breaking this out into a separate SVG Canvas > but I don't think the work reached a completion point. Does this mean it will be C++ classes? -- Ian Grant, Computer Lab., William Gates Building, JJ Thomson Ave., Cambridge Phone: +44 1223 334420

3 2

[Fwd: Re: inkscape]
by MenTaLguY 28 Nov '03

28 Nov '03

-----Forwarded Message----- From: Marek Peteraj <marpet@...83...> To: MenTaLguY <mental@...3...> Subject: Re: inkscape Date: Fri, 28 Nov 2003 16:33:14 +0100 On Thu, 2003-11-27 at 08:52, MenTaLguY wrote: > On Tue, 2003-11-25 at 11:40, Marek Peteraj wrote: > > Hi Mental, > > > > i just learned about inkscape, seems to be a very cool project, and as > > i'm not subscribed to the mailing list yet, i'd like to make a few > > suggestions: > > (sorry for the belated reply; I've been buried in mail) np :) > May I have your permission to forward your message to the Inkscape > mailing list? Yes of course, you can also forward this one. > I hadn't seen a recent version of the GIMP for some time; > I wasn't very > impressed with it the last time I used it, but it looks like they've > made some major changes to the UI. I'll have to work with it some more > soon and get a feel for what's new. Check out the latest release(iirc 1.3.22, i'm still on .18) and take your time to organize and dock your dialogs and toy around with it to get the feel of the UI :) Also see my gimp screenshot. Also i've made an inkscape screenshot to demonstrate why the gimp UI is so efficient(i'm a heavy gimp user, it's my everyday tool so to speak, it's been like that since 1.0 versions) Everybody bashing the gimp UI please forget 1.2 :) and check out the latest release of the 1.3.x development cycle, toy around with docking and reorganizing dialogs. So here it is: http://www.pleasewipeyourfeet.com/webtest/pr/inkscape.jpg In apps such as gimp and inkscape, tools and tools options/settings need to be accesible immidiately. Gimp solves that issue by providing a combined dock/tabbed interface. You click on a tool in the toolbox and the appropriate options appear in the tool options dialog, so there are general tool options dialogs which is bound to the toolbox. http://www.pleasewipeyourfeet.com/webtest/pr/gimp.jpg see the brush tool selected in the toolbox on the left, the brush tool options bottomright. The options in inkscape are accesible only through a menu, and thery're not dockable in any way which leads to a mess (13 dialogs open!). Gimp 1.2 suffered from the same problem. Gimp tends to organize the tools and options very efficiently, it seems to me that the key for designing such UI would be to determine what a tool is, isolate it and set the options for it. See the transformation dialog or the text dialog in the screenshot. Can these be tools? Of course they can :) Can Fill/Stroke or align be a tool? I think it can. Then put all those tools in a static toolbox. (and ask jimmac to make some cool stock icons :) Settings should be put else where, see gimps preferences. The toolbox should offer only drawing tools or tools closely related to drawing(as i stated in my previous mail). The current tree-like menu is a misconception and should be removed from HiG IMO. The purpose of hiding the tools should be to save some extra space and to organize tools in a logical way. 1. More nodes will introduce even more space consuption so it's not a win at all to use it for that purpose, and there are lots of tools that are not related to each other so what happens is that you make a node called 'miscelaneous' and put all those unrelated tools in there. This doesn't solve the 'break into categories' issue at all. 2. Gimp 1.3.x has introduced a somewhat shuffled toolbox(new tools added etc), and i had some hard time getting used at that. Node-like organizing introduces continuous 'shuffling' in that you always end-up having different nodes opened and closed, the toolbox changes it's size each time you expand/collaps a node. So the purpose of organizing into categories gets totally broken. 3. In a professional environment, where you need to work fast and reliable, a static toolbox is the most efficient thing you'd find. Once you learn it, it never changes. The tools need to be accesible immidiatelly, expanding and collapsing will just slow down the user and distract him from his work. Besides why would you want to toy around with collapsing/expanding when you just need a tool to work with? 4. If i want to use a tool which i haven't used yet and i'm not quite sure what it does, the category won't help me to understand that, for example "touch up" category won't explain what a smudge tool does. Stock icons should be as self-explanatory as possible, and tooltips should be used. If you still don't know and haven't managed to figure by trial&error, the manual should handle the rest. Another important point is: The C-SDI interface is a perfect replacement for a WiW like environment(window-in-window, see the screenshots in previous mail) when combined with the dock/tabbed UI and should be *enforced* by HiG for apps like gimp and inkscape or DTP apps, not considered to be removed. Compare the gimp screenshot with the other screenshots i've posted. Also once the user learns how to use one app, it's easy to learn how the other one works, which is also the purpose of HiG i guess - to unify the UI experience. A good idea would be to talk to the gimp developers and work together on UI usability issues in the future, the results would be included in next revisions of HiG for similar types of apps. There are 3 major advantages in adopting the gimp UI where possible: 1. unifying the UI in the graphics-aps domain 2. avoid reinventing the wheel, gimp has been developed since 1997(afaik) and can already be considered as a mature professional raster-based app. 3. adopting the UI from an opensource app instead of its proprietary counterparts(no WiW, docking for example). Simply put, it's time for gimp to have a professional vector-based brother :) Marek

1 0

[Fwd: inkscape]
by MenTaLguY 28 Nov '03

28 Nov '03

-----Forwarded Message----- From: Marek Peteraj <marpet@...83...> To: mental@...58... Subject: inkscape Date: Tue, 25 Nov 2003 17:40:51 +0100 Hi Mental, i just learned about inkscape, seems to be a very cool project, and as i'm not subscribed to the mailing list yet, i'd like to make a few suggestions: It seems that inkscape could become the gimp of vector graphics, that's why i think it would be really cool to design the UI to be as close to gimp as possible, since the gimp is pretty mature to date and it can already be considered as a porfessional tool for raster image manipulation. I took a look at the HiG and it's suggesting the same type of toolbox as sodipodi/inkscape offers. Honestly i must say that i *hate* that kind of organizing. :) The gimp toolbox is pretty slick and offers only drawing tools or tools closely related to drawing such as selections. The idea to organize them in collapsible "trees" seems completely broken to me since actually hiding the tools which you want to see in a toolbox, if expanded it makes the toolbox bigger, and a user that doesn't understand what each button/tool means has to learn it whether it's organized or not, the stock icons are rather self-explanatory and describe the tools in an understandable manner. So things i would suggest to avoid: 1. remove all items that aren't drawing tools or tools related to drawing, such as save as, open etc 2. avoid organizing in trees such as stated in HiG(unfortunately) 3. keep all buttons directly in the toolbox, hide them in pop-up colums(such as the dynahand in sodipodi) This is basically what gimp does. Next thing i'd like to suggest is to organize features in dialogs that are either dockable or organized in tabs. I've collected a few screenshots when i wanted to look at how all apps manage their features and functions. If you take a look at all of them, you'll find that they all look pretty much the same, dialogs on the right, toolbox on the left. Except that *only* gimp doesn't do WiW(window in window). And *only* gimp does provide a reasonable way to manage a lot of dialogs, namely 1) docking them and 2) organizing them in tabs. Gimp does manage tool/functions very carefully, it provides a UI model that is perfectly customizable, and groups features and functions in a clever way. http://www.pleasewipeyourfeet.com/webtest/pr/gimp.jpg http://www.pleasewipeyourfeet.com/webtest/pr/scribus.jpg http://www.qmedia.co.za/image/screen32791.jpg http://www.activewin.com/reviews/software/graphics/adobe/illustrator10/imag… http://www.suse.de/en/private/products/suse_linux/winerack/images/photoshop… http://www.activewin.com/reviews/software/graphics/adobe/pagemaker7/images/… A very important thing to consider here is whether to design the UI of those apps to be as close as possible to each other. This is perfectly possible since only gimp is a mature app to date and it's an app which provides an even more clever ui than it's proprietary counterparts. If we had 2-3 powerful apps that would create a professional linux graphics studio they would probably be: * gimp for raster image editing, photo retouching * inkscape for vector image editing * passepartout for DTP (it's in early devel stage currently so i can't tell right now) Keeping their UIs as close as possible is the key to build a pro linux graphics studio since the user isn't forced to get use to another type of ui. :) Marek

1 0

Re: [Inkscape-devel] Re: Planning for 0.37 goal
by bulia byak 28 Nov '03

28 Nov '03

> >As for the grid dialog, why separate dialog? Is it so big and complex it won't fit into the Grid tab of the current ctrl-shift-d dialog? > > > > > It's not big, in fact it is simpler. It's just that my changes mean > that I have to restructure the grid representation and it would be > easier to get right using C++, which is our planned language anyway. > It's not a separate dialog, so in fact my first step will probably be to > port the whole ctrl-shift-d dialog to gtkmm to get a feel for how things > work. Great! In the DialogsReorganization plan, the former "document settings" dialog is to be merged with the ctrl-shift-d too - its content should go on the Page tab. Assuming nobody objects to this idea, if you implement it too along with gtkmmization, that would be fantastic. Also, in a past milestone, there's a mention of a new export dialog. What's its status? Can we do it in gtkmm too? > Btw, I don't have close boxes on my dialogs (see attached png) > > My window manager is sawfish (default). Hmm, is this a case of the lack-of-decoration-on-transient-windows that we discussed some time ago? Or can it be fixed simply by adding a hint when the window is created? I'll try to see what can be done about that. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

utest
by Bryce Harrington 28 Nov '03

28 Nov '03

utest.inc 0. Very straightforward and basic testing. 1. Needs a copyright/licensing statement 2. Needs a README 3. Add doxygen comments for each function 4. Assert for NULL const char* inputs 5. strncpy character strings (line 20) 6. Maybe consider 't_' as the prefix for testing functions instead of 'utest_"? Might make it more concise and eye catching? repr-action-test.c 1. Document what it's doing in each stanza so if people use this as an example, it'll explain what's being done and why. Looks like a good start all around. Nice straightforward system with the basic capabilities. We can build on it as we learn more about testing. Bryce

1 0

Inkscape Subsystem Block Diagram
by Bryce Harrington 28 Nov '03

28 Nov '03

Mental and I put together this top-level block diagram of the Inkscape application today. http://www.inkscape.org/doc/ It identifies the 10 main "pieces" that make up Inkscape, what files belong to each of them, and roughly how they dovetail together. The main motivation for drawing this is to provide the team with a set of groupings that we can use to take a 'divide and conquer' approach to large efforts such as unit tests, documentation, or code style alterations. The original SVG is checked into CVS in inkscape/doc/. Bryce

1 1