
Do you all think "Windows" is a better name for the "Dialogs" menu, or does anyone have any better ideas?
-mental

If it were me, I'd put the dialogs for altering object properties (fill/stroke, text, etc.) in the Object menu, the XML Editor to the View menu (or maybe Edit), and the rest to a Preferences menu.
Also, some of the dialogs (like Tool Options) feel like they really want to be sub-panes of some larger dialog. So perhaps instead of a menu for Preferences, they could be combined into a single Preferences dialog, accessed via Edit or File.
Bryce
On Wed, 18 Feb 2004, MenTaLguY wrote:
Do you all think "Windows" is a better name for the "Dialogs" menu, or does anyone have any better ideas?
-mental

On Wed, 18 Feb 2004, MenTaLguY wrote:
Do you all think "Windows" is a better name for the "Dialogs" menu, or does anyone have any better ideas?
On Wed, 18 Feb 2004, Bryce Harrington wrote:
If it were me, I'd put the dialogs for altering object properties (fill/stroke, text, etc.) in the Object menu, the XML Editor to the View menu (or maybe Edit), and the rest to a Preferences menu.
I was hoping that much of the functionaly that is currently in the Dialogs menu will get moved from those dialogs to the secondary toolbar although some will of course need to be left as floating palettes/dialogs.
I was hoping that the XML Editor would be made a bit more seperable. Instead we would have a menu item View 'Source View' or suchlike which would present the XML Editor by default but if the user wanted to would present Conglomerate perhaps or maybe gVIM. I haven't got used to the XML editor yet and I still find gVim more useful because I really like syntax colouring like you wouldn't believe and I usually only look at the source to quickly remove large chunks of SVG or change the numbers of some points (usually rouding them to integers or something).
I think it is interesting from a usability point of view to look at why people are using the XML Editor, what problems is it being used to solve and is there a way to solve these problems automatically so users dont need to use an XML editor? I'll get back to you when I have thought about it in more depth.
Also, some of the dialogs (like Tool Options) feel like they really want to be sub-panes of some larger dialog. So perhaps instead of a menu for Preferences, they could be combined into a single Preferences dialog, accessed via Edit or File.
I'd like to see a unified preferences dialog too, and I'm hoping lots of import/export options can be put there instead of creating lots of extra dialogs or overloading the File Open and Save As (FOSA) Dialogs (and for I change I do realise I'm repeating myself)
Sincerely
Alan Horkan Inkscape Beta Tester ;) http://advogato.org/person/AlanHorkan/

Alan Horkan wrote:
If it were me, I'd put the dialogs for altering object properties (fill/stroke, text, etc.) in the Object menu, the XML Editor to the View menu (or maybe Edit), and the rest to a Preferences menu.
I was hoping that much of the functionaly that is currently in the Dialogs menu will get moved from those dialogs to the secondary toolbar although some will of course need to be left as floating palettes/dialogs.
Actually, I'd prefer things to be in menus. The more I play with the way menus work, the better I feel they suit most needs. dialogs tend to clutter up the screen. sure you can make them hidable, or even 'autohiding', where they disappear after a decission is made, but you are basically then trying to recreate a menu.
Lets put reasonable options in the menus rather than silly dialogs. For example, turning the grid on and off seems much more suited to a menu than hidden in some random dialog. Then you can associate the keybinding directly with the option, and people's spacial memory will help find the item again.
njh

El Viernes 20 Febrero 2004 00:21, Nathan Hurst escribió:
Alan Horkan wrote:
If it were me, I'd put the dialogs for altering object properties (fill/stroke, text, etc.) in the Object menu, the XML Editor to the View menu (or maybe Edit), and the rest to a Preferences menu.
I was hoping that much of the functionaly that is currently in the Dialogs menu will get moved from those dialogs to the secondary toolbar although some will of course need to be left as floating palettes/dialogs.
Actually, I'd prefer things to be in menus. The more I play with the way menus work, the better I feel they suit most needs. dialogs tend to clutter up the screen. sure you can make them hidable, or even 'autohiding', where they disappear after a decission is made, but you are basically then trying to recreate a menu.
Lets put reasonable options in the menus rather than silly dialogs. For example, turning the grid on and off seems much more suited to a menu than hidden in some random dialog. Then you can associate the keybinding directly with the option, and people's spacial memory will help find the item again.
You are completely right. The view stuff (rules, guide, etc) is being used all the time. Please do not use tabbed dialogs everywhere, and if they are, give the possibility to use them stand alone i.e. Fill and stroke: Three tabs for 2 areas. There should be two tabs and two menu entries: Fill, Stroke.
Néstor
njh
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

If The Gimp is not going to change it too then I wouldn't change it. I am also UI design aware, but in this case I prefer to keep cohesion a la Adobe between the "graphic applications suite". It helps when teaching you don't have to say "when you want to see the Option Window you have to go to the Dialog entry in The Gimp and to the Windows entry in Inkskape" I'm about to teach a 20 hours Photoretouch with the Gimp course for Secondary Schools Teachers (Public Education) and I'm planning to use Inkscape also. yours: Nestor
El Jueves 19 Febrero 2004 02:48, MenTaLguY escribió:
Do you all think "Windows" is a better name for the "Dialogs" menu, or does anyone have any better ideas?
-mental

On Thu, 19 Feb 2004, Nestor Diaz Valencia wrote:
Date: Thu, 19 Feb 2004 06:42:33 +0000 From: Nestor Diaz Valencia <nestordiaz@...207...> To: MenTaLguY <mental@...3...>, Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] 'dialogs' menu
If The Gimp is not going to change it too then I wouldn't change it.
I am also UI design aware, but in this case I prefer to keep cohesion a la Adobe between the "graphic applications suite". It helps when teaching you don't have to say "when you want to see the Option Window you have to go to the Dialog entry in The Gimp and to the Windows entry in Inkskape"
The Gimp uses a Controlled Single Document Interface (CDSI). Sodipodi does the same.
Inkscape uses SDI. This was a huge and incredibly significant change for which I will continue to praise Inkscape for a very long time.
The GIMP developers will very likely keep doing things the way they have been doing them. I cannot take the GIMP seriously in terms of usability when I get that kind of response because I'm not convinced a huge amount of thought went into why things were done that way in the first place. The GIMP could be helping to lead the way but at the moment it is playing it safe sticking with what they have. Which is fair enough except that other projects have followed the GIMP based on the assumption that they know exactly what they are doing.
It doesn't give me any pleasure to complain about the GIMP and I really try not to do it. The GIMP is good at what it does, it provides a toolset that makes many things possible but not necessarily easy and at a price that cant be beaten. But the GIMP isn't as good as Adobe Photoshop (and I can explain why if you really want) and in some ways I dont think it is even as Good as Paint Shop Pro (Versions 7 and 8 are really good and make it really easy to do some things quickly (like red-eye correction) as opposed to just the fairly raw tools in the GIMP that make it possible but not easy by default).
Inkscape is new and still willing to try things but still willing to change them and try other things if there are good reasons to do so and be the best that it can be.
Frankly when GIMP 2.0 goes Gold I'll be asking them again to reconsider things even though I expect them to strongly resist and refuse changes I really do want the GIMP to be more consistant with Gnome.
On the upside there is a bug report against the GIMP discussing menus like 'Script-Fu' and 'Perl-Fu' and there is some willingness to reorganise and streamline those menus by functionality and hide the implmentation details form the user (ie no longer grouped by programming language). Credit where credit is due: The GIMP 2.0 has still made many has a menubar which is very useful to a wide range of users and at the same time lets the older users keep doing things the way they are used to.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/

The GIMP developers will very likely keep doing things the way they have been doing them. I cannot take the GIMP seriously in terms of usability when I get that kind of response because I'm not convinced a huge amount of thought went into why things were done that way in the first place. The GIMP could be helping to lead the way but at the moment it is playing it safe sticking with what they have. Which is fair enough except that other projects have followed the GIMP based on the assumption that they know exactly what they are doing.
I know what you mean. When I open up PSP, all my palettes and such are exactly where I left them when I last used it. When it comes to the GIMP, Inkscape, etc, each palette is a seperate application, and I have to open them and move them each time I use it. Gets tiresome when Ihave to do this after a crash, etc. Right now that's my only complaint against Inkscape & sodipodi. I think if there was an open source implementation for palettes(instead of separate mini-apps) and a nice MDI arch, well, there would be much rejoicing.

Spitfire 1500 wrote:
I think if there was an open source
implementation for palettes(instead of separate mini-apps) and a nice MDI arch, well, there would be much rejoicing.
True. But not completely so, I tihnk.
Over the last few years of developing apps, I have found that people are generally split about 50-50 (IMHO) whether they prefer MDI and dockable toolbars or SDI and floating toolbars.
I think it is more of a function of people's desires when the GUI decisions are made. I also think that (and this may be sacrilege to some) style guides and HIG docs are just as much opinion and taste and anything else. I'm more of a "take it for a test drive" kind of guy. No single model fits all occasions.
But, yes, it is cool watching the guys who are good with GUIs (Bulia, for example) work out the problems for a good user interface.
Bob

The Gimp saves windows and palettes posittions lately. You can take a snapshot with your preferences whenever you want. Check it our Inkscape should do the same. What is more, There are some Dialogs in 0.37 that are not keeping themselves on top, like Tool Options Item Properties
Néstor
El Jueves 19 Febrero 2004 18:43, Bob Jamison escribió:
Spitfire 1500 wrote:
I think if there was an open source
implementation for palettes(instead of separate mini-apps) and a nice MDI arch, well, there would be much rejoicing.
True. But not completely so, I tihnk.
Over the last few years of developing apps, I have found that people are generally split about 50-50 (IMHO) whether they prefer MDI and dockable toolbars or SDI and floating toolbars.
I think it is more of a function of people's desires when the GUI decisions are made. I also think that (and this may be sacrilege to some) style guides and HIG docs are just as much opinion and taste and anything else. I'm more of a "take it for a test drive" kind of guy. No single model fits all occasions.
But, yes, it is cool watching the guys who are good with GUIs (Bulia, for example) work out the problems for a good user interface.
Bob
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

El Jueves 19 Febrero 2004 15:18, Alan Horkan escribió:
On Thu, 19 Feb 2004, Nestor Diaz Valencia wrote:
Date: Thu, 19 Feb 2004 06:42:33 +0000 From: Nestor Diaz Valencia <nestordiaz@...207...> To: MenTaLguY <mental@...3...>, Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] 'dialogs' menu
If The Gimp is not going to change it too then I wouldn't change it.
I am also UI design aware, but in this case I prefer to keep cohesion a la Adobe between the "graphic applications suite". It helps when teaching you don't have to say "when you want to see the Option Window you have to go to the Dialog entry in The Gimp and to the Windows entry in Inkskape"
The Gimp uses a Controlled Single Document Interface (CDSI). Sodipodi does the same.
Inkscape uses SDI. This was a huge and incredibly significant change for which I will continue to praise Inkscape for a very long time.
The GIMP developers will very likely keep doing things the way they have been doing them. I cannot take the GIMP seriously in terms of usability when I get that kind of response because I'm not convinced a huge amount of thought went into why things were done that way in the first place. The GIMP could be helping to lead the way but at the moment it is playing it safe sticking with what they have. Which is fair enough except that other projects have followed the GIMP based on the assumption that they know exactly what they are doing.
you don't need to explain it, I'm aware of The Gimp lack of features for proffessional prepress.
From a UI point of view, maybe The Gimp is not perfect, but either Photoshop.
In spite that piracy has made photoshop quite common, is not a product targeted for a consumer user. Yes, it has nice filters, mostly for artistic and web purposes (the default ones I mean) but you can ask anybody who makes his/her live working with Photoshop and there a few profs that has used a few filters in their job. For that reason, The Gimp is as suitable as Photoshop for this kind of tasks. Not to mention FilmGimp/Cinepaint. As I said before, photoshop's UI is not the best one, but is this type of product that was the first in it's breed and people are used to it for no reason just because they are used to it. In fact, Photoshop for mac (the most used platform for designers for a while) had CDSI, and the windows version was MDI. Now, is my opinion that Inkscape should follow The Gimp language as long as it's possible. Just to make thing's easier. Adobe has a common tool language and this is the way proffesionals are used to switch from one app to another. And maybe is easier too to switch from one system (win) to another (opensource).
I am working in an icon theme for Inkscape to match as much as possible The Gimp interface, a la Macromedia Suite, Corel Suite and Adobe Suite. Another nice common feature is the dockable palettes. Inkscape could benefit from that, this last mostly thinking in a future Inkscape that will have Layers, Objecttree, Timeline, Patterns, etc ;).
If you are looking for a consumer photo retouch applications in the opensource world, try Perico, I think it's quite easy. No compiling needed.
It doesn't give me any pleasure to complain about the GIMP and I really try not to do it. The GIMP is good at what it does, it provides a toolset that makes many things possible but not necessarily easy and at a price that cant be beaten. But the GIMP isn't as good as Adobe Photoshop (and I can explain why if you really want) and in some ways I dont think it is even as Good as Paint Shop Pro (Versions 7 and 8 are really good and make it really easy to do some things quickly (like red-eye correction) as opposed to just the fairly raw tools in the GIMP that make it possible but not easy by default).
Inkscape is new and still willing to try things but still willing to change them and try other things if there are good reasons to do so and be the best that it can be.
Frankly when GIMP 2.0 goes Gold I'll be asking them again to reconsider things even though I expect them to strongly resist and refuse changes I really do want the GIMP to be more consistant with Gnome.
I don't because I don't use Gnome, so I would like as less Gnome libraries as possible.
On the upside there is a bug report against the GIMP discussing menus like 'Script-Fu' and 'Perl-Fu' and there is some willingness to reorganise and streamline those menus by functionality and hide the implmentation details form the user (ie no longer grouped by programming language). Credit where credit is due: The GIMP 2.0 has still made many has a menubar which is very useful to a wide range of users and at the same time lets the older users keep doing things the way they are used to.
You are right, the menu gives lot's of newbies a horizont to not get lost :)
Yours: Néstor Díaz.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
participants (7)
-
Alan Horkan
-
Bob Jamison
-
Bryce Harrington
-
MenTaLguY
-
Nathan Hurst
-
Nestor Diaz Valencia
-
Spitfire 1500