- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Re: dnd [was: Re: export patches]
by bulia byak 25 Dec '03

25 Dec '03

Hi Alexander, big thanks for your file-related fixes today! However there's a problem with the error messageboxes you added (this also applies to the export errors) - they must be: - modal - unsinkable (transient) - non-resizeable The new save confirmation dialog satisfies all these requirements - please borrow the settings from it for your messageboxes. _________________________________________________________________ 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] Re: dnd [was: Re: export patches]
by bulia byak 25 Dec '03

25 Dec '03

>The new save confirmation dialog satisfies all these requirements - please >borrow the settings from it for your messageboxes. Also, please make transient the file selection dialog opened by the Browse button, as are the file open and save dialogs (all it requires is a call to sp_transientize()). And the progress bar window must be transient too. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

1 0

Re: Bugfix for file open crashing
by bulia byak 25 Dec '03

25 Dec '03

Hi, Thanks for the patch - but exactly this problem was fixed today, just a few hours before you :) However, if you're interested in Inkscape, please keep contributing! There remain a lot of unfixed bugs and unimplemented features, and we're always looking for new developers :) -- bb _________________________________________________________________ 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…

1 0

Re: [Inkscape-devel] User Interface(was: save confirm dialog)
by bulia byak 25 Dec '03

25 Dec '03

> > I left these because I'm still undecided on whether we want the Initial >Caps > > style. To me it sounds old-fashioned and clunky, I would like to change > > everything to First cap only. But it's not something I feel too strongly > > about, so if HIG mandates Initial Caps without exceptions, I can live >with > > that. > >Yep it does. And to me, being used to it, everything else looks like an >oversight and thus unprofessional. :) It's described here: >http://developer.gnome.org/projects/gup/hig/1.0/layout.html#layout-capitali… OK, then please go ahead and unify that. > > >- Removed shortcut labels from the context menu. This is according to > > >the HIG to reduce clutter. > > > > Disagree. "Reduce clutter" is not a strong enough argument for me. The > > sooner the user will learn shortcuts, the more productive he will be, so >I'd > > like to use any opportunity to remind the shortcuts. > >Hm ok, I'll revert the change. However, to be honest I don't understand >the reason and I really don't believe that it is a strong enough reason >to break consistency. To me, it's more consistent when all menus show shortcuts, no matter context or not. >Users can learn the shortcuts from the main menu >and users who use the context menu usually do that because they want to >have quick access to a certain function, not because they want to see >the shortcut. Exactly BECAUSE they want quick access, they will be glad to learn that there's a still quicker access, via the shortcut :) > > If the former, well, OK. Otherwise, I like Ctrl-Shift better, because it > > seems to be standard on Windows, and besides it's more natural because >it's > >Is consistency with Windows more important than consistency with GNOME? >That would be a mild disappointment for me. :/ They are equally important. Winning users from Windows or Mac is of major importance, simply because it's by far the biggest source of new users. Given that Linux was feeling all right without a good vector editor for many years is an indication that the core users of Linux may not need such an application all that much. On the other hand, I'm an example of a person who've been rebooting into Windows for the vector editors (in my case, it's mostly Xara X) until I found Inkscape and spent some time on making it usable for me (with much help from others, of course - something that makes Inkscape very different from e.g. Sodipodi). So now I do simple designs in Inkscape, although I still have to reboot into Windows for more complex tasks. To summarize, neither Windows nor Gnome are the final authority for us; but both are worth consulting. Where HIG is in minor disagreement with Windows or Mac practices, we should follow HIG (unless doing otherwise brings some sizable benefits). But where following HIG literally might seriously alienate or confuse Windows users, we must be extra careful. Ideally each decision should be taken based on usability tests with real users, but lacking that, we need to put forward convincing arguments in addition to references to standards or conventions. > > the order in which most people actually press these keys (Ctrl, then >Shift). > > So I'd like to leave this as is unless there's some strongly worded and > > convincingly argued standard on this. > >Again, I don't think that this is a good reason to break consistency. >There is also a good reason for Shift+Ctrl+X: Most shortcuts are Ctrl+X, >Shift+Ctrl+X is usually only used when this one is already taken. So >putting Shift on the left side will make the items align better: >Bounce Ctrl+B >Frobnicate Ctrl+F >Foobar Shift+Ctrl+F >as opposed to: >Bounce Ctrl+B >Frobnicate Ctrl+F >Foobar Ctrl+Shift+F That's a counterpoint, but still I'm not convinced. I think following the natural order of pressing buttons is of major importance for the shortcut to be easy to memorize. Anyone else has an opinion? > > Key names: actually I wrote a special function (sp_key_name in > > interface.cpp) to translate from the ugly GDK names to normal ones. >Mostly > > it replaces monsters like "asciicircum" by its character, i.e. "^", but >also > > changes Page_Down. Reason: (1) it's overly long and unwieldy, (2) the >"_" > > character is not really meant for user consumption, it's a programmer's > > device, and (3) PgUp/PgDn is standard on Windows. So I would like to >keep > > this as is. > >Hmm ok. Again, the break of consistency kinda irks me and the "is >standard on Windows" irks me even more. ;) But right now this a minor >issue anyway... I needed a shorter variant for Page_Down, and Windows has one. Why not use it? > > "base" is the namedview. I think we can drop it. But the digit must be >kept, > > it the number of the view (call View/New view, it will show the same > > document with ": 2"). > >Ok. How about showing the ": x" only when it's two or higher? Good idea I think. > > >- Toolbar is non-standard (also looks ugly with Bluecurve theme :/) > > > > Which one, primary or secondary? > >Secondary. OK, you could work on it too, see SecondaryToolbar on wiki for the plans :) The difficulty with it is that we want to put both buttons and other kinds of controls there (spinbuttons, lists) and it may not be straightforward to combine them neatly. >Primary is fine. Though the HIG mandates that if a vertical toolbar is >used, the user should be able to make it horizontal. Probably not very >important, but I wonder if we could make it possible to also dock it at >the top when it's dragged around? May be relatively easy to implement, although now I don't see an urgent need for that. > > >- Storing window size when a window is closed and restoring this size > > >when a new window is opened. Currently new windows open way too small > > >for my resolution. Would that be ok? > > > > Done yesterday :) see my message "namedview news" > >Oh, great! :) I missed that. But this doesn't work for new documents, >right? I mean without using a template. It would be nice if a new >document would always open with the size of the last window I closed. I think this is wrong, because if I have several documents open with different window sizes and I quit Inkscape, the size of the new one will depend on which was closed last, which is almost random (from user perspective anyway). So this behavior might be confusing. I think it's better to decide once and for ever that "I want new documents to be this large" and put this into the template. Again, anyone else has an opinion on this? >Alright, I'll have a look at the preferences dialog then, this was >interesting me anyway. :) For everything else I'll wait for the >conversion to Gtkmm, as I'm really looking forward to that. Is there any >estimate already when this switch will occur? I couldn't find it in the >roadmap. Is there anything I could do to help with this? I think Nathan Hurst or Mental are the right persons to ask this question. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

5 6

Re: [Inkscape-devel] User Interface(was: save confirm dialog)
by bulia byak 25 Dec '03

25 Dec '03

>Agreed, also there isn't really any natural order. It doesn't matter >which button you press first and I'm pretty sure that not everyone >presses Ctrl, then Shift, then the key. Also many people (like me) have >a keyboard where control actually is located above shift. So this >argument is weak IMHO. :) Oh, OK, I changed the order. See now :) >Hmm, I meanwhile think that Bulia is right actually. Saving the size >only for "real" documents leads to a nice document oriented behavior. >And if it's easy to make the current size of the window the default size >for new documents, then everyone should be happy. I'd say as long as we >keep the document oriented behavior (opening a new document always opens >a new window, so a window _is_ the document), this is sane. In fact, we >should have a real spatial application right now. :) That's very nice >from a usability perspective. I added a Template tab to the PreferencesDialog wiki page where the user can edit any aspects of the template or press "Take from the current document". _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

1 0

namedview news
by bulia byak 25 Dec '03

25 Dec '03

Finally! Now when you save a document, its zoom and view center are written to sodipodi:namedview in the SVG file and restored on load. Moreover, optionally Inkscape saves and restored window geometry for each document (size and position). Whether this is done is controlled by options.savewindowgeometry in the preferences; for now I set this to 1 so you can test this feature. Still more, reading a template from preferences now works (some rudimentary code was there but it didn't work properly). This means you can pull the sodipodi:namedview element from any of your documents and insert it into your ~/.inkscape/preferences.xml into the group with id="template", for example: <group id="template"> <sodipodi:namedview id="base" inkscape:zoom="13.6834309" inkscape:cx="345.390036" inkscape:cy="184.555047" inkscape:window-width="1268" inkscape:window-height="999" inkscape:window-x="0" inkscape:window-y="0" showgrid="true"> <sodipodi:guide orientation="vertical" position="481.748035" id="guide573" /> </sodipodi:namedview> </group> and all new documents you create will have the zoom and window geometry of that document, plus its guides, grid, and other settings. There's no UI for setting this template yet, but it's easy to add a command that will save the current document's namedview into the preferences, with a given id (which is "base" by default, but we can add a variant of the New command that selects one of the namedviews stored in preferences. Or perhaps it's better to leave one namedview template only in preferences, but add a "New from template" command that creates a new document from a separate empty SVG file that will store not only the namedview but paper size, etc.). _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] menu idea
by bulia byak 25 Dec '03

25 Dec '03

>Hm, Dialogs is pretty generic. But I guess it's the best choice, since >Tools would probably be too confusing. >Oh the other hand, after we reorganize the dialogs there should be only >7 left, More will be added, Layers for one. >if we move Preferences to Edit, only 6. Do we have to? Is this some kind of a standard? >This would make the View >menu contain only 15 items View will grow too; for example we need menu commands to switch rulers and grid on/off. >including the dialogs and that's an >acceptable number, so maybe it's not really worth it? We could then >still split the menu once it grows too large. I think it's better if users can get accustomed to the new menu layout early. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] menu idea
by bulia byak 25 Dec '03

25 Dec '03

>Please remember that in some languages, the menu names will be about >twice their current width. Do you really want the document window >forced to be that wide? Currently the menu takes about 25% of my screen horizontally, so we definitely have some room to grow. Besides, we'll also have much more stuff in the secondary toolbar that will also stretch the window horizontally (although of course we must be very thrifty with space there and add important things closer to the left side) >Forgetting for the moment what the standard widgets can currently do, >what do you think the best way to deal with uncomfortably wide menus is? I don't think it's an issue at this time. Inkscape will have big menus inevitably, since it's a complex application. Gimp now has 10 menus; it simply cuts the menubar when window is resized small - I don't like that, I'd prefer the menus to be reflown in 2 or more lines (does GTK support that?) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1

menu idea
by bulia byak 24 Dec '03

24 Dec '03

With the View menu moved, I think it makes sense to serparate its list of dialogs into a separate menu Dialogs, to be put after Object. And I'd like to separate Object into Object (grouping, order, and transformation commands) and Path (everything else). What do you think? This makes 8 menus overall, which is not too many I think. With this arrangement, it seems to be much easier to find a place for a new command (there hopefully will be many). _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 2

item-specific context menuitems
by MenTaLguY 24 Dec '03

24 Dec '03

Just a quick note -- in HEAD, I've removed the per-class submenus from the context menu and lumped the menuitems onto the main context menu. This still doesn't really fix the problems with the context menu, but at least it's moderately less crappy now. -mental

1 0