- Inkscape Devel - Inkscape Mailman

Re: GIMP user interface discussion
by bulia byak 29 Nov '03

29 Nov '03

Hello Sven, Thanks for taking time to answer my comments. I hope you don't mind if I cc my response to the Inkscape list. As I wrote, I only spent one day playing with the new Gimp and did not claim to be able to discover everything it's capable of doing. I'm glad to hear Gimp is so configurable, however the first impressions are important, and maybe you can use the feedback of the fresh-eye, first-time users to change some defaults. > The majority of palettes (dialogs) are still not transient and > "sink" readily when you switch to the document window that overlaps > them. Working with a maximized document window is therefore next to > impossible. Some of the dialogs/palettes are transient, though - I > think it's those that can only apply to the current document and are > more or less "modal", i.e. you cannot do anything on the canvas > while such a window is active (examples are Levels, Color balance, > etc.) Making such modal windows transient is indeed a step in the > right direction, as in Gimp 1.2 even they could be buried easily > (and confusingly for most users). However, having to dig out my > primary toolbox from under a pile of windows still drives me crazy. > > Some people prefer the toolbox and the docks to stay on top, others > hate this. So it's up to you to set the utility window type hint in > the GIMP perferences and to configure your WM to keep these windows on > top. Most window managers seem to handle utility windows like this by > default. I have never heard before about "the utility window type hint". My KDE (3.1.3) does not seem to be aware of such windows at all, I don't see how I can configure that. If you use the hint that most WMs are unaware of, you must either bug the WM developers to implement it (the high profile of Gimp does give you some power to do that, IMHO) or offer some better supported ways to do the same. For example, if you add a third option, "transient", to the "window type hints" list in Preferences and make that the default (both for toolbox and for docks), I think the default Gimp will behave in a more expected way for the majority of new users (while remaining usable for those who prefer another behavior.) > The main toolbox is also exempt from docking. This means that > although you now have a way to reduce the number of windows on your > desktop, you still have at least three windows (document, toolbox, a > group of docked palettes) that you'll have to alt-tab your way > through. > > That is simply wrong. You can dock to the bottom of the toolbox just > like to any other dock. The only difference is that the toolbox > doesn't offer an image menu. We suggest to dock the tool-options to > the toolbox but it's up to you to configure your preferred setup. Indeed! However, unlike tabs, I could not drag-and dock the toolbox to another dock, which is why I did not realize how it can be docked. That is, unlike tabs, you cannot grab the toolbox at an empty menubar space and drag it to another dock. Also, there's no way to add a toolbox to a dock via the "Add tab" menu. I think the interface must be consistent: if the toolbox is dockable, it must behave exactly like all other dockables. > Weirdly, the single-letter keys for switching tools only work in the > document window. > > We hope to get the problem of the global accelerator table sorted out > before 2.0. Things will definitely become a lot better with the UI > manager that will be part of GTK+-2.4. So GIMP-2.2 is supposed to > have a much better global handling of shortcuts. Glad to hear that. It's important. In Inkscape, global keys really work everywhere now, while in Gimp, I cannot even press Ctrl-q to exit if I'm inside a dock! > The palettes are so "independent" that they don't even care to track > the current document. Switch from one document to another and watch > your Layers palette, for example. Does it show you the layers of the > new document? Nope! You have to use another palette called Images to > select what document is being displayed. > > That's simply not true. You can set each dock to "Auto Follow Active > Image" in the dockable menu and it will update with the active > image. If you add an image menu, there's that "Auto" button next to it > which gives the same functionality. Please note that this is the > default configuration that The GIMP will start with when it is > launched for the first time. I noticed that menu option and it was indeed on, but it did not do anything for me. As I now see, there's one more thing I had to do: "Activate the focused image" in Preferences must be on. Please make that setting on by default, too. Still, even with "Auto follow", I see no way to move focus from a dock to the active image using keyboard. > Zoom shortcuts are inconvenient. "-" on the keyboard zooms out > without shift, but to zoom in I have to press "+" with shift. Keypad > - and + do not work at all. > > It may be inconvenient on your keyboard layout, but why don't you > reconfigure it then? Go to the Prefs dialog and enable "Dynamic > Keyboard Shortcuts", hover your mouse over the Zoom menu entry and > press your favorite key. Sure, but zoom keys are the first any user will try to use, why not make them more convenient by default? > Fullscreen mode is actually designed as a way to view your document > w/o any distracting user interface elements. It's not supposed to be > used for editing. However since some people prefer to do the latter, > you can configure the fullscreen appearance of the image window in > Preferences. If you follow my advice to set the utility window type > hint, your toolbox and docks should also float on the image window in > fullscreen mode. Wonderful, but see above on the "utility type hint". -- bb -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

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