Re: [Inkscape-devel] save confirm dialog
Not sure about the time (although why not?), but one thing we absolutely need is an indication of whether the sodipodi:modified is on or not. On windows, it's conventional to add * to the filename in the title bar,
don't
know what HIG says about this.
True. With showing the time, I meant in the dialog however. As the HIG suggests: http://developer.gnome.org/projects/gup/hig/1.0/images/save_alert.png I believe that's very useful. :) So far only Mr.Project seems to have this feature.
A nice touch. At the moment, though, we probably have more urgent UI holes to patch...
I just posted another patch. :)
See my comment in the tracker. We'll probably also need Mental or anyone else knowing Pango to review it.
As for CVS, hm, why not. But to be honest, I'm not a very reliable person and I tend to switch a lot between different interests, so I'm not sure if it's really worth it. At least I can't promise that I will do much. :) At the moment I feel pretty motivated to work on the user interface though, so if it's no big effort for you, it would be nice.
No problem, you're in. Welcome to the team :) And I know by experience that CVS access is addictive, and a good motivation for people to keep contributing :) Please still use the patch tracker for dangerous changes that may need review, but feel free to patch any small or obvious things right in the CVS (our motto is "patch now, discuss later" :) Also you might want to read the UI section on our Wiki to get an idea of the major plans and discussions in this area. (If you'd be able to help with any of tasks there, such as reorganization of dialogs or building the secondary toolbar, that would be fantastic!)
_________________________________________________________________ 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%2f...
On Tue, 23 Dec 2003, bulia byak wrote:
As for CVS, hm, why not. But to be honest, I'm not a very reliable person and I tend to switch a lot between different interests, so I'm not sure if it's really worth it. At least I can't promise that I will do much. :) At the moment I feel pretty motivated to work on the user interface though, so if it's no big effort for you, it would be nice.
No problem, you're in. Welcome to the team :) And I know by experience that CVS access is addictive, and a good motivation for people to keep contributing :) Please still use the patch tracker for dangerous changes that may need review, but feel free to patch any small or obvious things right in the CVS (our motto is "patch now, discuss later" :) Also you might want to read the UI section on our Wiki to get an idea of the major plans and discussions in this area. (If you'd be able to help with any of tasks there, such as reorganization of dialogs or building the secondary toolbar, that would be fantastic!)
Yup, welcome aboard!
In addition to the patch tracker, feel free to take ownership of any bugs or feature requests you'd like to work on. And have a look at the Roadmap page in Wiki, which shows specific tasks we identified as needing done prior to the next release.
Also, we encourage use of setting up a CVS branch for significant work that might break the tree for other developers. There's a page in Wiki describing how to set up (and later merge) branches if you've not done it before.
Bryce
----- Original Message ----- From: "Bryce Harrington" <bryce@...1...> . Thanks Bob for supplying the 20/12/03 build.
Hey, since you have all three [Win32] versions on hand, can you report on
how
well they each work?
Thanks, Bryce
Yes. I'll do some comparisons as soon as I can get Xmas out of the way. :-)
vellum vellum@...68...
On Tue, 2003-12-23 at 07:53, Bryce Harrington wrote:
No problem, you're in. Welcome to the team :) And I know by experience that CVS access is addictive, and a good motivation for people to keep contributing :) Please still use the patch tracker for dangerous changes that may need review, but feel free to patch any small or obvious things right in the CVS (our motto is "patch now, discuss later" :) Also you might want to read the UI section on our Wiki to get an idea of the major plans and discussions in this area. (If you'd be able to help with any of tasks there, such as reorganization of dialogs or building the secondary toolbar, that would be fantastic!)
Yup, welcome aboard!
In addition to the patch tracker, feel free to take ownership of any bugs or feature requests you'd like to work on. And have a look at the Roadmap page in Wiki, which shows specific tasks we identified as needing done prior to the next release.
Also, we encourage use of setting up a CVS branch for significant work that might break the tree for other developers. There's a page in Wiki describing how to set up (and later merge) branches if you've not done it before.
Thank you. :) I have now committed my first tiny CVS change (another world premiere for me :D), it doesn't seem that difficult.
As I'd especially like to work on polishing the user interface, I think I should probably ask you first about your position on the HIG, etc. I noticed that many parts of the UI are still not HIG compliant or very non-standard for no obvious reason. The best example probably is the secondary toolbar, which shows buttons instead of typical toolbar icons. But there are also smaller examples where I'm unsure, for example I wonder if there is a specific reasons to show all shortcuts as lowercase instead of uppercase. In general, how committed are you to the HIG and interface standards? :) And should I ask before each change?
Daniel
On Tue, 23 Dec 2003, Daniel Borgmann wrote:
Thank you. :) I have now committed my first tiny CVS change (another world premiere for me :D), it doesn't seem that difficult.
Congrats!
As I'd especially like to work on polishing the user interface, I think I should probably ask you first about your position on the HIG, etc. I noticed that many parts of the UI are still not HIG compliant or very non-standard for no obvious reason. The best example probably is the secondary toolbar, which shows buttons instead of typical toolbar icons. But there are also smaller examples where I'm unsure, for example I wonder if there is a specific reasons to show all shortcuts as lowercase instead of uppercase. In general, how committed are you to the HIG and interface standards? :) And should I ask before each change?
Daniel
Good questions. While you're coming up to speed I think you'd find it very worthwhile to ask a lot of questions of the other developers. I would encourage you to use both the mailing list and Jabber to float ideas. Once folks are really comfortable with where you're coming from, I think you'll find it less necessary to seek feedback (although it's still worth it!)
Regarding HIG, yes it's definitely something we're committed to, although I think we all still wish to see the HIG issues brought up on the list so we all have a chance to understand them. It's even possible we may find some given HIG item to actually hamper the interface, and so we want to ensure we can identify those items for deeper investigation. It's possible we may choose to not follow the HIG on some item, and/or try to feed that decision back into the standard.
One thing that could be very useful at this point would be to simply list the areas where Inkscape has HIG compliance issues. This would allow folks to voice thoughts about items that'd be important and/or easily fixed low hanging fruit, and so the list could be prioritized.
Hope this helps! Bryce
On Tue, 2003-12-23 at 22:50, Bryce Harrington wrote:
Regarding HIG, yes it's definitely something we're committed to, although I think we all still wish to see the HIG issues brought up on the list so we all have a chance to understand them. It's even possible we may find some given HIG item to actually hamper the interface, and so we want to ensure we can identify those items for deeper investigation. It's possible we may choose to not follow the HIG on some item, and/or try to feed that decision back into the standard.
Alright, that sounds reasonable. I think I'll just hack away on smaller issues and then ask before I commit.
One thing that could be very useful at this point would be to simply list the areas where Inkscape has HIG compliance issues. This would allow folks to voice thoughts about items that'd be important and/or easily fixed low hanging fruit, and so the list could be prioritized.
Yeah I thought about that, however reviewing the entire application and making sure everything is confirm, is actually quite an undertaking. =) So I decided not to try to do it all at once (maybe we are lucky and someone does a real UI review of Inkscape).
However, I currently have done some changes which I'd like to commit if you are fine with them, so here they are:
- Fixed some capitalization mistakes ("Remove transformations" -> "Remove Transformations", etc) and added ellipses were appropriate (like "Import..." and "Export Bitmap..."). I also changed "x:x" in the View menu to "Zoom x:x" as in Totem. We shouldn't take it too far with the abbreviations. ;)
- Added mnemonics. For this I had to change some functions to their _with_mnemonic counterpart and also had to add some underscores to many action names (for example "Open" would become "_Open"). I hope this is not a problem. It should only be a problem, if those action names are meant to used at places where mnemonics can't be used. And if they are, we have a major problem.
- Changed the position of the "View" and "Object" menus. View is a standard menu which should come at the third position according to the HIG, application specific menus should come after the standard menus.
- Removed shortcut labels from the context menu. This is according to the HIG to reduce clutter. To make this possible, I added sp_ui_context_menu_append_item_from_verb(), which does the same as sp_ui_menu_append_item_from_verb(), but without drawing the shortcut label. This might not be the most elegant solution, but I thought it was better than to change the existing function call (correct me when I'm wrong).
The whole menu stuff in Inkscape seems to be pretty non-standard and I wonder if it wouldn't be worth simplifying the code (maybe using the new action-based API from libegg which will be in Gtk 2.3?). I mostly don't like the way how items with shortcuts are constructed as a new container, as this makes it impossible for Gtk to properly space the menus (notice how in other Gtk apps, the item labels never overlap with the shortcut labels of other items, but they do in Inkscape). And I don't think that this can be solved easily without rewriting some parts of the menu handling.
Other obvious HIG issues which I didn't touch yet: - The shortcut labels are non-standard. :) Aside from the already mentioned lowercase letters, they also use the wrong ordering sometimes (Ctrl+Shift+C would be Shift+Ctrl+C in other Gtk applications) or wrong names (PgUp should be Page_Up).
- The context menu is really bad. You probably know that already. :) The main point of the context menu is to provide quick access to the most commonly used action on an object. Most commonly used actions should be at the top and sub menus should be avoided. Of course the current context menu breaks all of this. :) This deserves some discussion and a good plan IMO. Maybe a Wiki page?
- The title name of the app is "Inkscape: Documentname: base: X". According to the HIG it should be either just "Documentname" or "Documentname - Inkscape". I don't know yet what this "base: x" is supposed to be, only that it looks odd. :)
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
So it would be great to have some decisions on those issues.
Other than that, I'd like to look at the following things next:
- 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?
- Dialog reorganization. :) Should I know anything (besides what's written on the Wiki pages) before I play around with this? Did anyone already work on it?
Daniel
On Wed, 24 Dec 2003, Daniel Borgmann wrote:
One thing that could be very useful at this point would be to simply list the areas where Inkscape has HIG compliance issues. This would allow folks to voice thoughts about items that'd be important and/or easily fixed low hanging fruit, and so the list could be prioritized.
Yeah I thought about that, however reviewing the entire application and making sure everything is confirm, is actually quite an undertaking. =)
Likely true. Even doing just a subset would probably be valuable, especially if the remainder could be identified as discrete tasks that others could do later. Basically, my thinking is that it would be nice if we had a grasp on "how" compliant it is, and a way to know when we can say we've completed the HIGification work.
However, I currently have done some changes which I'd like to commit if you are fine with them, so here they are:
- Fixed some capitalization mistakes ("Remove transformations" ->
"Remove Transformations", etc) and added ellipses were appropriate (like "Import..." and "Export Bitmap..."). I also changed "x:x" in the View menu to "Zoom x:x" as in Totem. We shouldn't take it too far with the abbreviations. ;)
Good, that helps make the menus more consistent with standards.
- Added mnemonics. For this I had to change some functions to their
_with_mnemonic counterpart and also had to add some underscores to many action names (for example "Open" would become "_Open"). I hope this is not a problem. It should only be a problem, if those action names are meant to used at places where mnemonics can't be used. And if they are, we have a major problem.
I think Bulia would be the best to give feedback on this one.
- Changed the position of the "View" and "Object" menus. View is a
standard menu which should come at the third position according to the HIG, application specific menus should come after the standard menus.
Okay.
- Removed shortcut labels from the context menu. This is according to
the HIG to reduce clutter. To make this possible, I added sp_ui_context_menu_append_item_from_verb(), which does the same as sp_ui_menu_append_item_from_verb(), but without drawing the shortcut label. This might not be the most elegant solution, but I thought it was better than to change the existing function call (correct me when I'm wrong).
Hmm, IIRC Bulia put these in deliberately, so I would discuss this one with him before committing it. He had some reasons for doing it so it would be good to gain concensus with him. I suspect it will come down to needing to make a decision whether we want to actively promote learning the keyboard shortcuts vs. strict adherance to the HIG. It may be in this case that the arguments favoring learning would take precidence over merely "reducing clutter". Talk with Bulia and get his take on it.
The whole menu stuff in Inkscape seems to be pretty non-standard and I wonder if it wouldn't be worth simplifying the code (maybe using the new action-based API from libegg which will be in Gtk 2.3?). I mostly don't like the way how items with shortcuts are constructed as a new container, as this makes it impossible for Gtk to properly space the menus (notice how in other Gtk apps, the item labels never overlap with the shortcut labels of other items, but they do in Inkscape). And I don't think that this can be solved easily without rewriting some parts of the menu handling.
For this talk with Mental. Also keep in mind that we want to convert all of this to Gtkmm at some point anyway, so I think if you'd be up for rewriting it, that may be encouraged. However, make sure to discuss with Mental regarding handling of verbs, as he has definite plans for where we're going with that.
Other obvious HIG issues which I didn't touch yet:
- The shortcut labels are non-standard. :) Aside from the already
mentioned lowercase letters, they also use the wrong ordering sometimes (Ctrl+Shift+C would be Shift+Ctrl+C in other Gtk applications) or wrong names (PgUp should be Page_Up).
This sounds like a good change, to me, but get Bulia's feedback on this, just to be sure you're on the same page with it.
- The context menu is really bad. You probably know that already. :) The
main point of the context menu is to provide quick access to the most commonly used action on an object. Most commonly used actions should be at the top and sub menus should be avoided. Of course the current context menu breaks all of this. :) This deserves some discussion and a good plan IMO. Maybe a Wiki page?
Yes, the context menu needs heavy rework. Discussion and planning on Wiki is a good idea. Also, I think if you'd like to go ahead and start revising it, it'd be well received. Probably send in your first few couple tries as patches for review - Mental would be good to give some feedback that you're using the right approach.
I have a sense that getting the context menu right would be a killer feature for Inkscape, since it can be such a dominant input mechanism for mouse-oriented artists, so this would be a high priority item.
- The title name of the app is "Inkscape: Documentname: base: X".
According to the HIG it should be either just "Documentname" or "Documentname - Inkscape". I don't know yet what this "base: x" is supposed to be, only that it looks odd. :)
base is probably the name of the root node in the XML doc. No idea why that would show up in the title. I'd say go ahead and make this change, as to my knowledge there are no stakeholders for the current approach. So this can be a normal 'patch first, discuss later' thing. I think it'd be nice to keep 'Inkscape' in the name, if feasible.
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
So it would be great to have some decisions on those issues.
I showed the app to a co-worker yesterday and he had the same comment. Especially with the raise/lower buttons, which are difficult to distinguish. I wonder if the old pre-0.27 Sodipodi icons would be better?
Other than that, I'd like to look at the following things next:
- 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?
Yup, give it a shot and we'll see what folks think of it.
- Dialog reorganization. :) Should I know anything (besides what's
written on the Wiki pages) before I play around with this? Did anyone already work on it?
You're welcome to get started on this one. The thinking was that we would do this as we converted each to Gtkmm, but there's probably little reason not to do one before the other. A nice mockup of a replacement for the object properties dialog was done; you should be able to find a pointer to it from the news archive page on the website. All of the established thinking is on Wiki, although Mental and/or Bulia may be worth mining for additional ideas. In any case, to my knowledge nobody is actively working on this currently.
Make sure to do this work in a CVS branch. This way you can have folks the reorganized approach you'll be proposing before it gets committed to the main branch.
Bryce
On Wed, 2003-12-24 at 13:09, Bryce Harrington wrote:
- The title name of the app is "Inkscape: Documentname: base: X".
According to the HIG it should be either just "Documentname" or "Documentname - Inkscape". I don't know yet what this "base: x" is supposed to be, only that it looks odd. :)
base is probably the name of the root node in the XML doc. No idea why that would show up in the title. I'd say go ahead and make this change, as to my knowledge there are no stakeholders for the current approach. So this can be a normal 'patch first, discuss later' thing. I think it'd be nice to keep 'Inkscape' in the name, if feasible.
It's actually the name of the namedview, and the number is which instance of that namedview, as I recall. "Documentname - Inkscape" looks good to me though (in fact I believe it's the HIG-recommended form).
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
So it would be great to have some decisions on those issues.
I showed the app to a co-worker yesterday and he had the same comment. Especially with the raise/lower buttons, which are difficult to distinguish. I wonder if the old pre-0.27 Sodipodi icons would be better?
The icons need reworking.
Additionally, the ugliness with some themes is going to be due to SPIcon (similar to GtkImage). We now use standard widgets, otherwise.
SPIcon renders an alpha-channeled image and composites it against a rectangle of the background color of the parent widget. Obviously this won't work so well with themes that don't use a solid background color, or have odd rules for color usage.
The real solution is to composite directly over whatever the parent widget drew (as GtkImage does), but X doesn't do alpha compositing at this point in time.
Ideally I'd rather use GtkImage for this (particularly so we could leverage GtkIconFactory), but it currently uses binary transparency masks rather than true alpha -- our rescaled SVG icons could look really nasty around the edges.
I think the direction to go is to redo the SVG icons with the pixel sizes in mind, so they won't look so bad when thresholded. Or perhaps go back to pixmap icons in general. Not sure.
-mental
On Wed, 24 Dec 2003, MenTaLguY wrote:
I think the direction to go is to redo the SVG icons with the pixel sizes in mind, so they won't look so bad when thresholded. Or perhaps go back to pixmap icons in general. Not sure.
One advantage to consider regarding going back to pixmap icons is that since they're pre-rendered, it could help reduce start-up time, especially if we plan to have more buttons, and aren't doing anything to take advantage of the scalability/transparency aspects of svg.
Bryce
Bryce Harrington wrote:
One advantage to consider regarding going back to pixmap icons is that since they're pre-rendered, it could help reduce start-up time, especially if we plan to have more buttons, and aren't doing anything to take advantage of the scalability/transparency aspects of svg.
So, how much time does it save?
Supposedly, librsvg can be faster than libpng for a comparable image in many cases. So what type of savings are we talking here? Or is this another case of premature optimization? ;-)
On Wed, 24 Dec 2003, Jon A. Cruz wrote:
Bryce Harrington wrote:
One advantage to consider regarding going back to pixmap icons is that since they're pre-rendered, it could help reduce start-up time, especially if we plan to have more buttons, and aren't doing anything to take advantage of the scalability/transparency aspects of svg.
So, how much time does it save?
Supposedly, librsvg can be faster than libpng for a comparable image in many cases. So what type of savings are we talking here? Or is this another case of premature optimization? ;-)
They're being rendered by libnr not librsvg. The stroke-drawing code getting accessed hundreds or thousands of times during startup with a blank document.
Bryce
Bryce Harrington wrote:
On Wed, 24 Dec 2003, Jon A. Cruz wrote:
So, how much time does it save?
Supposedly, librsvg can be faster than libpng for a comparable image in many cases. So what type of savings are we talking here? Or is this another case of premature optimization? ;-)
They're being rendered by libnr not librsvg. The stroke-drawing code getting accessed hundreds or thousands of times during startup with a blank document.
The point remains - please profile it before changing it. Using SVGs removes one level of human error remembering to autogen the pngs. I would be surprised if the stroking code really does take too long - plenty of games do stroking at 60fps on complex structures.
njh
On Thu, 25 Dec 2003, Nathan Hurst wrote:
The point remains - please profile it before changing it. Using SVGs removes one level of human error remembering to autogen the pngs. I would be surprised if the stroking code really does take too long - plenty of games do stroking at 60fps on complex structures.
All I'm saying is that if the choice is made to go to pixmap buttons for some reason, it may *also* have the benefit of faster startup time. No I haven't conducted a conclusive profiling analysis nor do I have any interest in doing so, just pointing it out as another potential advantage.
Picking one function randomly from style.c, sp_style_merge_from_parent is getting called 1503 times when starting up with no document.
Bryce
On Thu, 2003-12-25 at 03:44, Nathan Hurst wrote:
The point remains - please profile it before changing it. Using SVGs removes one level of human error remembering to autogen the pngs.
Dude, if we go back to pixmap icons, that's what Makefiles are for.
Remember that inkscape can be used for batch rendering from the commandline, after all...
-mental
Daniel Borgmann wrote:
- Fixed some capitalization mistakes ("Remove transformations" ->
"Remove Transformations", etc) and added ellipses were appropriate (like "Import..." and "Export Bitmap..."). I also changed "x:x" in the View menu to "Zoom x:x" as in Totem. We shouldn't take it too far with the abbreviations. ;)
I hope you added ellipsis... We've already got ellipses. :)
njh
participants (7)
-
Bryce Harrington -
bulia byak -
Daniel Borgmann -
Jon A. Cruz -
MenTaLguY -
Nathan Hurst -
vellum