NEW: Gtkmmified Document Preferences Dialog
Hello, the new Document Preferences Dialog is now default in CVS. Please report any bugs you might find, and that are not mentioned here. Changes /wrt the old versions include:
- included Carl's new snapping widgets by collecting everything snapping related on ond page - Grid and Guide widgets are on the same page - metadata widgets are spread over two pages, making the dialog height smaller - fixed 1366507 - grayed out license URI has too low contrast --> no longer grayed - fixed 1366504 - proprietary license should clean license uri - fixed 1357224 - no spinbutton tooltips - fixed 1232941 - minor grid quirks - implemented 1251393 (rfe) - canvas color should ignore bkg alpha value - dramatic reduction of code size due to usage of widget objects - used widget objects should be reusable by other dialogs, too - much more readable code; thus, less comments.
still todo, but will be done before 0.44:
- 1370648 - save as LGPL license not possible. huh? lgpl? ==> will remove LGPL from list - color picker windows don't close/hide together with doc prefs - on activedoc changed - set better DEFAULTS for grid + snapping
Also, I would appreciate help on issues that apparently affect only the Win32 version:
win: "dialog expands on startup" win: "license combo very wide"
best ralf
On Mon, 2005-12-12 at 17:57 +0100, Ralf Stephan wrote:
Hello, the new Document Preferences Dialog is now default in CVS. Please report any bugs you might find, and that are not mentioned here. Changes /wrt the old versions include:
- included Carl's new snapping widgets by collecting everything snapping related on ond page
- Grid and Guide widgets are on the same page
- metadata widgets are spread over two pages, making the dialog height smaller
- fixed 1366507 - grayed out license URI has too low contrast --> no longer grayed
- fixed 1366504 - proprietary license should clean license uri
- fixed 1357224 - no spinbutton tooltips
- fixed 1232941 - minor grid quirks
- implemented 1251393 (rfe) - canvas color should ignore bkg alpha value
- dramatic reduction of code size due to usage of widget objects
- used widget objects should be reusable by other dialogs, too
- much more readable code; thus, less comments.
still todo, but will be done before 0.44:
- 1370648 - save as LGPL license not possible. huh? lgpl? ==> will remove LGPL from list
- color picker windows don't close/hide together with doc prefs
- on activedoc changed
- set better DEFAULTS for grid + snapping
Also, I would appreciate help on issues that apparently affect only the Win32 version:
win: "dialog expands on startup" win: "license combo very wide"
First of all, awesome that you have converted these dialogs.
Here are a couple of from the hip comments:
In my build everthing is crammed together.
IMO, the metadata should still be on one pane. It is strange to see two metadata tabs.
Also, the checkboxes/actual enabling for the grid and show guides takes really long to check and uncheck.
Jon
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
In my build everthing is crammed together.
Can you be more specific? Also, others don't report that. Which system?
IMO, the metadata should still be on one pane. It is strange to see two metadata tabs.
Having one would make the dialog overly high. There was a complaint about that to which I agree.
Also, the checkboxes/actual enabling for the grid and show guides takes really long to check and uncheck.
Again, I don't see this on Linux. Is this Windows? If so, I would need help from a Windows developer.
ralf
Ralf,
Thanks for the change. Overall it looks better now, though there are many small cosmetic issues that I'd like to fix. So far I found two bigger issues:
- The show-grid checkbutton does not respond in any way when I switch grid on and off by the # key. Previously, the checkbox reflected that live, i.e. while the dialog is open. I can (reluctantly) agree to disabling this live update, but then, it does not change even if you close/reopen the dialog! That is, open the dialog, press #, close dialog, open it again - it still has the show grid checkbox off even though the grid is visible. This must be fixed for this and other checkboxes which apply to things that can be changed from keyboard.
- It crashes when switching the license to "proprietary".
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 12 Dec 2005, Ralf Stephan wrote:
[..]
still todo, but will be done before 0.44:
- 1370648 - save as LGPL license not possible. huh? lgpl? ==> will remove LGPL from list
Admittedly this is weird but I'm not sure it is weird enough to remove it entirely. I've seen GPL and LGPL programs and the included artwork/data files is intended to also be under the same license. In practice trying to apply the LGPL to items other than source code is messy but the lines get a bit blurry when it comes to scripting languages or data files.
I guess the point is if users expect to be able to do this should they be prevented from doing it?
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
Quoting Alan Horkan <horkana@...44...>:
On Mon, 12 Dec 2005, Ralf Stephan wrote:
[..]
still todo, but will be done before 0.44:
- 1370648 - save as LGPL license not possible. huh? lgpl? ==> will remove LGPL from list
Admittedly this is weird but I'm not sure it is weird enough to remove it entirely.
Agreed ... GPL/LGPL makes more sense for SVG than it would for most graphics formats. I think we should offer it as an option. Just not near the top of the list as a subtle discouragement.
-mental
Ralf Stephan wrote:
- implemented 1251393 (rfe) - canvas color should ignore bkg alpha value
Shouldn't this be handled by just making the Canvas Alpha default to 255 (as opposed to the old 0) and still have it be configurable as opposed to the current /locking/ Alpha at 255? If we're not outside the spec, it seems like a step backwards to me. In general, the more flexibility the better. It also appears to me that the person that filed the RFE is unaware of how transparency in PNGs works (and is trying to work with it more like you would with a GIF). Setting the level of transparency for the canvas (and background) is definitely useful, as I know I've utilized it quite a bit in the past myself. Just my .02.
-Josh
- implemented 1251393 (rfe) - canvas color should ignore bkg alpha
Shouldn't this be handled by just making the Canvas Alpha default to 255 (as opposed to the old 0) and still have it be configurable as opposed to the current /locking/ Alpha at 255? If we're not
This would just mean to change every template svg, right? Unless there is a complaint, this will be done (and the dialog behaviour reverted).
ralf
On 12/13/05, Ralf Stephan <ralf@...748...> wrote:
This would just mean to change every template svg, right? Unless there is a complaint, this will be done (and the dialog behaviour reverted).
Wait a minute, why "every"?!
We already have opaque white and opaque black templates. They work fine. If there's a majority of votes in favor of that, we can switch the default template from transparent to opaque, and then have the transparent template as an alternative option (but I vote against this change). But there's absolutely no need to change "every" template to opaque.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 12/12/05, Joshua A. Andler <joshua@...533...> wrote:
Ralf Stephan wrote:
- implemented 1251393 (rfe) - canvas color should ignore bkg alpha value
Sorry I didn't notice that RFE before. Now that I see it I think I rather disagree with it. It postulates an equivalence of two colors - the color under the SVG/PNG image and the background color of the SVG. These two are NOT the same, however. For example I may want to have a 50% opaque black background in PNG over a yellow page. With this change, it becomes impossible to create e.g. black art on a partially opaque black background, because the background will now become totally opaque and the black objects will be invisible. Also, it's awfully counterintuitive - for any object changing its transparency has a visible effect but for the background it does not, why?
As for the example given by the RFE author, I usually do this by adding a background rectangle of the color I need to a new layer. Then I just hide that layer before export. This takes some time but at least it's logical.
Now, the ideal way to handle this would be to store TWO changeable colors: one is the SVG background with its transparency, and the other is the color _under_ the background, to which the background would blend (currently fixed white). This way we'll satisfy everyone. But before that is done, the current scheme is at least more logical and requires less awkward explanations than the scheme proposed in that RFE.
So, I propose that you please consider reverting that change.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting Ralf Stephan <ralf@...748...>:
There is no decision on opaqueness of default.*svg but with my vote for it we have 2:1. My reason is that I once have been bitten by it, and without doubt, countless others.
More opinions?
I don't have a strong opinion, but I wouldn't object to making that change.
Thinking about it, it's more common for me to want an opaque background color when exporting than not.
On the other hand, defaulting to opaque may surprise people who e.g. plan to use their SVGs in Firefox rather than rendering them to a bitmap.
-mental
On Tuesday 13 December 2005 16:54, mental@...3... wrote:
Quoting Ralf Stephan <ralf@...748...>:
There is no decision on opaqueness of default.*svg but with my vote for it we have 2:1. My reason is that I once have been bitten by it, and without doubt, countless others.
More opinions?
I don't have a strong opinion, but I wouldn't object to making that change.
Thinking about it, it's more common for me to want an opaque background color when exporting than not.
On the other hand, defaulting to opaque may surprise people who e.g. plan to use their SVGs in Firefox rather than rendering them to a bitmap.
As a non-dev, I'll put up my hands for keeping transparent as default. I'd think "what is placed on the page is just that, no page background interfering in my export".
my 2c
Craig
On 12/13/05, Craig Bradney wrote:
Thinking about it, it's more common for me to want an opaque background color when exporting than not.
On the other hand, defaulting to opaque may surprise people who e.g. plan to use their SVGs in Firefox rather than rendering them to a bitmap.
As a non-dev, I'll put up my hands for keeping transparent as default. I'd think "what is placed on the page is just that, no page background interfering in my export".
Then you would prefer chessboard instead of solid color fill in teh background, wouldn't you? :)
I still make the same mistake with export, when I just forget whether BG is transparent or opaque white and I'm pretty sure I'mnot the only one ;)
Alexandre
Rationale for keeping default.svg transparent:
- Our background color is non-compliant SVG, until we implement background color attr newly added to SVG 1.2. With it being transparent, at least a _majority_ of docs will be compliant, because SVG 1.1 says the renderer must make background transparent. So, currently you have to do something for it to become different-rendered-in-batik. With this change you will get that by default.
- When a newbie gets unwanted transparent bg on export, s/he will likely realize it can be turned off somewhere, or at least s/he can add a opaque bg rect to work around this. When, vice versa, s/he gets opaque export whereas transparency was desired, s/he has no easy workarounds, and no easy way to guess that that this is fixable at all.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting bulia byak <buliabyak@...400...>:
Rationale for keeping default.svg transparent:
[SVG compliance]
[newbie expectation]
Hmm. Both are good points. I guess I'd have to come out against making the default opaque, and additionally since SVG with Firefox is going to be a "growth market" for us. There, the standard SVG background behavior will dominate.
-mental
mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
Rationale for keeping default.svg transparent:
[SVG compliance]
[newbie expectation]
Hmm. Both are good points. I guess I'd have to come out against making the default opaque, and additionally since SVG with Firefox is going to be a "growth market" for us. There, the standard SVG background behavior will dominate.
I thought I had written a reply before, but I can't find any proof of that now. :)
It seems to me that the two most common use cases are fully transparent and fully opaque backgrounds. It also seems that these options apply far more often to PNG export than to anything having to do with SVG.
What about displaying theses options in some sort of widget in the PNG export dialog?
Aaron Spike
Quoting aaron@...749...:
That's the problem. People who get bitten don't even care about export. They want the background on screen have color.
Whoa! Really? Please detail "bitten."
They set the new color and "nothing happens".
Since the canvas background color is originally white and the background is white, they may not necessarily make the connection that alpha also needs to be adjusted.
Rendering a checkerboard on the canvas for transparent backgrounds would be another way to fix that, but I don't think people would like that very much.
-mental
Quoting aaron@...749...:
What about displaying theses options in some sort of widget in the PNG export dialog?
Hmm!
Actually, yes, I vote we move the background color widget from document preferences to bitmap export. That's the only thing it affects, after all.
Once we implement the SVG 1.2 version, then we can put one back in document preferences again too perhaps.
-mental
mental@...3... wrote:
Quoting mental@...3...:
Actually, yes, I vote we move the background color widget from document preferences to bitmap export. That's the only thing it affects, after all.
And... nope. I'm wrong on this one too.
Heh. Let me be more specific. Color/transparency should still be configured from the document prefs. Nothing else would make any sense. But for convenience and in order to place the option before users eyes at the appropriate time, I would use a radio button with three options:
Background Color Alpha o Fully Opaque o As Configured in Document Preferences o Fully Transparent
Aaron Spike
On 12/13/05, aaron@...749... <aaron@...749...> wrote:
Background Color Alpha o Fully Opaque o As Configured in Document Preferences o Fully Transparent
Sounds terribly redundant and confusing to me. Now, when tweaking the transparency slider, I also have to remember to set the switch to "as configured", otherwise it won't work... brrr.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Real beginners (90% of new users) want to "just change background color" but nothing happens.
Is it even explained in the tutorials that A means opacity? Please raise at least _some_ effort to keep users who don't have read the SVG spec. As Aaron says, there a chance to act educational.
ralf
On 12/13/05, Ralf Stephan <ralf@...748...> wrote:
Is it even explained in the tutorials that A means opacity?
Just hover your mouse over it and it will say so in the tooltip. Also the widget itself is pretty self-explanatory.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 12/13/05, bulia byak <buliabyak@...400...> wrote:
Sorry I didn't notice that RFE before. Now that I see it I think I rather disagree with it. It postulates an equivalence of two colors - the color under the SVG/PNG image and the background color of the SVG. These two are NOT the same, however. For example I may want to have a 50% opaque black background in PNG over a yellow page.
I'm the one who submitted that RFE. Now that you mention it, I see my mistake. Yes, the drawing surface color is different than the image background color.
As for the example given by the RFE author, I usually do this by
adding a background rectangle of the color I need to a new layer. Then I just hide that layer before export. This takes some time but at least it's logical.
This is what I do too, and is the real reason I submitted the RFE. All I want to do is change the color of the Inkscape drawing surface while still having a _fully transparent_ image background for export, browser rendering, etc.. There is no way to do this currently, and adding a rectangle only to hide it later is an uncomfortable hack.
Now, the ideal way to handle this would be to store TWO changeable
colors: one is the SVG background with its transparency, and the other is the color _under_ the background, to which the background would blend (currently fixed white). This way we'll satisfy everyone. But before that is done, the current scheme is at least more logical and requires less awkward explanations than the scheme proposed in that RFE.
This is certainly the way to go. Actually, I do not think the drawing surface color should have a transparency option at all. Since there is nothing under it, transparency makes no sense. In fact, we already _have_ a drawing surface color - it's just fixed white with no way to change it.
So, I propose that you please consider reverting that change.
Agreed. Should I submit a new RFE for "adjustable drawing surface color?" One of these days I'll learn GTK and start making these changes myself.
-s_tec
William Swanson wrote:
One of these days I'll learn GTK and start making these changes myself.
Why not start today? ;) Seriously, we've diagnosed the problem and agreed upon a solution. The difficult part is done. I assume by your comment that you must have some C/C++ experience or GTK/GTKMM wouldn't be the stopping point. In my experience the more talented Inkscape developers have always taken the time to help me break a task down and discuss implementation details. We'd love to have you help out!
Aaron Spike
On 12/13/05, aaron@...749... <aaron@...749...> wrote:
William Swanson wrote:
One of these days I'll learn GTK and start making these changes myself.
Why not start today? ;) Seriously, we've diagnosed the problem and agreed upon a solution. The difficult part is done. I assume by your comment that you must have some C/C++ experience or GTK/GTKMM wouldn't be the stopping point. In my experience the more talented Inkscape developers have always taken the time to help me break a task down and discuss implementation details. We'd love to have you help out!
I just graduated from college this weekend, and am in the middle of moving to a new place and starting a new job. Once these things are settled, I'll be ready to start coding again. :)
-s_tec
hi
Now that the dialog has been completely rewritten why not make it comply with the Gnome HIG guidelines?
(I don't now if it is already following then, but the one that is used right now is not following them)
Diego
On 12/13/05, Diego González wrote:
hi
Now that the dialog has been completely rewritten why not make it comply with the Gnome HIG guidelines?
Could it possibly be an equivalent of Andreas Nilsson's mockup [1] for Preferences dialog?
[1] http://hagemaenner.de/stuff/inkscape/preferences/inkscape_new_prefs_mockup3....
Alexandre
On Tue, 13 Dec 2005, Alexandre Prokoudine wrote:
Date: Tue, 13 Dec 2005 13:13:12 +0300 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: Gtkmmified Document Preferences Dialog
On 12/13/05, Diego Gonz�lez wrote:
hi
Now that the dialog has been completely rewritten why not make it comply with the Gnome HIG guidelines?
Could it possibly be an equivalent of Andreas Nilsson's mockup [1] for Preferences dialog?
[1] http://hagemaenner.de/stuff/inkscape/preferences/inkscape_new_prefs_mockup3....
Inkscape has both "Inkscape Preferences" and "Document Preferences" and it is only the latter which has recently been redone using GtkMM. Having two menu items both of which are described as Preferences is confusing to me and I think you may also have been confused and mixed up the two.
I equate the first of these "Inkscape Preferences" with what other applications would call Preferences or Options. (And I must say it seems very unusual to me to include branding overtly in the menu labels.)
The second is more like and a mix of both Page Setup and Properties (Document Properties, also known as metadata as seen in Office applications like Gnumeric) neither of which would normally be designed like palettes or expect to be left open.
I dont think there was much (any?) disagreement the proposal for the main Preferences dialog with a Tree View and everything would be something great to have and we would all be much happier about.
There were quite strong disagreements about my suggestion to reorganise the latter Document Preferences which this thread was discussing but I would be interested if people could explain more about why they like the current always open palette based design for options (and especially metadata) which I wouldn't have thought required such frequent changing that you would want have a compact dialog open all the time. Perhaps there might be room to make thing a little more like how other applications do things?
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
would be interested if people could explain more about why they like the current always open palette based design for options (and especially
In the case of snapping, having the possibility of an open page that handles all snapping and that could be left open to access it frequently was a main reason to put all snap related widgets onto one page.
ralf
On Wed, 14 Dec 2005, Ralf Stephan wrote:
Date: Wed, 14 Dec 2005 18:21:16 +0100 From: Ralf Stephan <ralf@...748...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: Gtkmmified Document Preferences Dialog
Part of what I'm getting at is I believe if users need to change preferences on a regular basis something else must be wrong. We should be able to put more of these things into a transient* dialog and more some of the options elsewhere.
(* It could be non-modal and left open of a user really wanted but just it would be designed more like a dialog and not using the compact palette dialog which implies it is intended to be left open all the time)
would be interested if people could explain more about why they like the current always open palette based design for options (and especially
In the case of snapping, having the possibility of an open page that handles all snapping and that could be left open to access it frequently was a main reason to put all snap related widgets onto one page.
As Inkscape gains more features a menu reorganisation including submenus and more menu items will be needed, which could include a menu item for Snap to Grid. The idea of tieing it in directly to the show grid functionality didn't really work out and putting it back in the menus seems like it would be the right thing to do so long as it was part of a wider reorganisation.
I do seriously want to try coming up with a plan to reorganise the menus but to do it properly I think it will require a lot more than just rearranging existing items (perhaps I'll find time over the holidays).
As or the Docuent propeties dialog I do believe it can be changed to be more like what people might expect from other software without losing the core features people like about it now.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On 12/14/05, Ralf Stephan wrote:
would be interested if people could explain more about why they like the current always open palette based design for options (and especially
In the case of snapping, having the possibility of an open page that handles all snapping and that could be left open to access it frequently was a main reason to put all snap related widgets onto one page.
Oh no, I hope you are not going to make people keep it open all the time just to toggle snapping :) Why not a toolbar?
Alexandre
Alexandre Prokoudine wrote:
On 12/14/05, Ralf Stephan wrote:
would be interested if people could explain more about why they like the current always open palette based design for options (and especially
In the case of snapping, having the possibility of an open page that handles all snapping and that could be left open to access it frequently was a main reason to put all snap related widgets onto one page.
Oh no, I hope you are not going to make people keep it open all the time just to toggle snapping :) Why not a toolbar?
I think that this is an excellent question... in fact, is it possible for us to have a bunch of mini-toolbars for similar purposes? The only example I can think of off hand is the way that toolbars work in Windows. You can have toolbars with just a couple items on them, and have them side-by-side in one row (which it doesn't looks like our interface can do currently). I bring this up because I'd love to have a toolbar showing the icons for the boolean ops, and also the buttons for inset/outset and a spinbox to adjust the amount right there too, the snapping options in another, etc. Just a thought. I'm most interested to know Bulia's opinion on such things.
-Josh
On 12/14/05, Joshua A. Andler <joshua@...533...> wrote:
I think that this is an excellent question... in fact, is it possible for us to have a bunch of mini-toolbars for similar purposes? The only example I can think of off hand is the way that toolbars work in Windows. You can have toolbars with just a couple items on them, and have them side-by-side in one row (which it doesn't looks like our interface can do currently). I bring this up because I'd love to have a toolbar showing the icons for the boolean ops, and also the buttons for inset/outset and a spinbox to adjust the amount right there too, the snapping options in another, etc. Just a thought. I'm most interested to know Bulia's opinion on such things.
Of course I would welcome this. The only thing we're missing for that is a toolbar widget which:
1 can be torn off, float, and snap back to designated locations
2 can STAY ON TOP of the window (the current one sinks, which makes it useless)
3 can group with other short toolbars to make one long toolbar, with the ability to rearrange small toolbars in the combined large one by dragging.
Not exactly rocket science, this has been available to other apps for years. But GTK(mm) only gives us 1 - no 2, and afaik no 3.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
(I don't now if it is already following then, but the one that is used right now is not following them)
Please be more specific, the same applies to Alexandre.
Seeing the style of the Inkscape Preferences mockup, this design appears to use a treeview instead of notebook pages, and to replace checkbuttons with radiobuttons, so rewrite would be necessary.
This would be on the bottom of the todo list (probably not 0.44) so you both have enough time for specific design proposals.
ralf
Ralf Stephan wrote:
(I don't now if it is already following then, but the one that is used right now is not following them)
Please be more specific, the same applies to Alexandre.
Is hard to be specific without seeing the dialog and that means building yourself from CVS. Some screenshots would be useful.
Seeing the style of the Inkscape Preferences mockup, this design appears to use a treeview instead of notebook pages, and to replace checkbuttons with radiobuttons, so rewrite would be necessary.
The current Inkscape Preferences dialog is probably the worst part of the interface, so sooner or later a rewrite *will* be necessary.
This would be on the bottom of the todo list (probably not 0.44) so you both have enough time for specific design proposals.
On 12/13/05, Nicu Buculei <nicu@...398...> wrote:
The current Inkscape Preferences dialog is probably the worst part of the interface, so sooner or later a rewrite *will* be necessary.
If that rarely used (in theory at least), and quite logical in itself even if clumsy, dialog is "the worst part" of the interface, then I'd say we are in a pretty good form UI-wise...
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Dec 13, 2005, at 3:58 AM, Ralf Stephan wrote:
Seeing the style of the Inkscape Preferences mockup, this design appears to use a treeview instead of notebook pages, and to replace checkbuttons with radiobuttons, so rewrite would be necessary.
Remember, checkbuttons are for individual on/off items while radiobuttons are for sets of mutually exclusive, "one-and-only-one of the following" options.
Jon Cruz:
Remember, checkbuttons are for individual on/off items while radiobuttons are for sets of mutually exclusive, "one-and-only-one of the following" options.
You mean I cannot legally substitute
a checkbutton saying "Show Grid"
with
a radiobutton saying
"The grid will be o shown o hidden"?
ralf
On Dec 13, 2005, at 9:57 AM, Ralf Stephan wrote:
You mean I cannot legally substitute
a checkbutton saying "Show Grid"with
a radiobutton saying "The grid will be o shown o hidden"?
Generally not.
Aside from taking up more space, most user expectations would conflict with the latter.
For example, in my mail program, one "Junk Mail" page of preferences has "Enable junk mail filtering" as a single checkbox, but three different "When junk mail arrives" options as three radio buttons (leave it in inbox and flag, move to junk mailbox, or perform custom actions)
The HIG section on checkboxes is at http://developer.gnome.org/projects/gup/hig/2.0/controls-check- boxes.html
and radio buttons are at http://developer.gnome.org/projects/gup/hig/2.0/controls-radio- buttons.html
Ralf Stephan wrote:
(I don't now if it is already following then, but the one that is used right now is not following them)
Please be more specific, the same applies to Alexandre.
Seeing the style of the Inkscape Preferences mockup, this design appears to use a treeview instead of notebook pages, and to replace checkbuttons with radiobuttons, so rewrite would be necessary.
This would be on the bottom of the todo list (probably not 0.44) so you both have enough time for specific design proposals.
ralf
Hi there! I did that mockup and I can't remember replacing checkbuttons with radiobuttons on purpose, must have done that by mistake. "Show grid" with a checkbutton for example is so much smarter to have than "Show grid" with a on and off radiobutton, takes up less space too. I need to revisit this mockup a bit. For example, I don't think the frames are nessesary. Both as the GNOME hig advices them not to be used, and because they are just noise anyway. - Andreas
participants (13)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
Andreas Nilsson -
bulia byak -
Craig Bradney -
Diego González -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
Nicu Buculei -
Ralf Stephan -
William Swanson