Okay, I've removed our gtkmm dependency for now.
I did preserve Spark's close confirmation dialog, although I reworked it a little bit to conform to standard Gtk practice.
-mental
On Wed, 2003-12-31 at 23:08, MenTaLguY wrote:
Okay, I've removed our gtkmm dependency for now.
Too bad, I really liked gtkmm. :) Now that it seems to be much further away (Bryce talking about up to a year), should we work fullspeed ahead on the interface in C instead of waiting for the Gtkmm transition? I'm mainly thinking about dialogs and the secondary toolbar stuff.
I did preserve Spark's close confirmation dialog, although I reworked it a little bit to conform to standard Gtk practice.
Ok... The problem is, while it it's more in line with general Gtk practice at the moment, it's not in line with the HIG, which explicitly suggests to use larger spacing, no separator and no title. :/ But I understand that it's probably more reasonable to wait for Gtk (or the HIG) to be fixed instead of doing such a custom hack as I did. I'd suggest though to at least change the title just to "Warning", because with the current verbose title, the user practically has to read three sentences. That looks a bit too busy IMO. This is also the standard Gtk practice (in fact, I think it's the standard title if no string is provided).
Daniel
On Fri, 2004-01-02 at 12:48, Daniel Borgmann wrote:
On Wed, 2003-12-31 at 23:08, MenTaLguY wrote:
Okay, I've removed our gtkmm dependency for now.
Too bad, I really liked gtkmm. :)
Argh, indeed, me too. TT
Now that it seems to be much further away (Bryce talking about up to a year), should we work fullspeed ahead on the interface in C instead of waiting for the Gtkmm transition? I'm mainly thinking about dialogs and the secondary toolbar stuff.
Well, while we'll have to stick with Gtk+'s C API for a while, I'd definitely like to start using C++ features where it's useful to do so, even in the UI code.
I did preserve Spark's close confirmation dialog, although I reworked it a little bit to conform to standard Gtk practice.
Ok... The problem is, while it it's more in line with general Gtk practice at the moment, it's not in line with the HIG, which explicitly suggests to use larger spacing, no separator and no title. :/ But I understand that it's probably more reasonable to wait for Gtk (or the HIG) to be fixed instead of doing such a custom hack as I did.
As a rule I think we should choose standard (non-depreciated) widgets over HIG, since it means less code for us to maintain (and the standard widgets will eventually get fixed for HIG as you say).
( I guess if the standard stuff commits a particularly egregious HIG violation, then it's still worth hacking ourselves -- I think this is more of a cosmetic thing though. )
I'd suggest though to at least change the title just to "Warning", because with the current verbose title, the user practically has to read three sentences. That looks a bit too busy IMO. This is also the standard Gtk practice (in fact, I think it's the standard title if no string is provided).
Ok. Makes sense.
-mental
Build 20040102.
When Inkscape opens normally the text is not 100% black. It comes up slightly gray. This is due to the Alpha fill level opening at 0.75. This is easy to fix in preferences since it seems to come from the "tools" style = "fill:none; fill-opacity: 0.75;" Changing this to 1 fixes the problem.
Is there a reason for this 0.75 value? If not I suggest it gets changed so that the default references file has this value as 1.
Would this classify as a bug?
vellum
Did this issue get fixed or entered in the bug tracker? I've not seen this behavior myself but am guessing it'd be a quick fix?
Bryce
On Sat, 3 Jan 2004, vellum wrote:
Build 20040102.
When Inkscape opens normally the text is not 100% black. It comes up slightly gray. This is due to the Alpha fill level opening at 0.75. This is easy to fix in preferences since it seems to come from the "tools" style = "fill:none; fill-opacity: 0.75;" Changing this to 1 fixes the problem.
Is there a reason for this 0.75 value? If not I suggest it gets changed so that the default references file has this value as 1.
Would this classify as a bug?
vellum
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bryce Harrington wrote:
Did this issue get fixed or entered in the bug tracker? I've not seen this behavior myself but am guessing it'd be a quick fix?
Bryce
On Sat, 3 Jan 2004, vellum wrote:
Build 20040102.
When Inkscape opens normally the text is not 100% black. It comes up slightly gray. This is due to the Alpha fill level opening at 0.75. This is easy to fix in preferences since it seems to come from the "tools" style = "fill:none; fill-opacity: 0.75;" Changing this to 1 fixes the problem.
Is there a reason for this 0.75 value? If not I suggest it gets changed so that the default references file has this value as 1.
Would this classify as a bug?
vellum
Hi!
Heh. When you guys reply, you might trim the tails. ;-).
Would changing this entry at line 37 in preferences-skeleton.h be sufficient?
If so, I will do it...
" <group id="tools"" " style="fill:none;fill-opacity:0.75;"
Bob
On Mon, 2 Feb 2004, Bob Jamison wrote:
On Sat, 3 Jan 2004, vellum wrote:
When Inkscape opens normally the text is not 100% black. It comes up slightly gray. This is due to the Alpha fill level opening at 0.75. This is easy to fix in preferences since it seems to come from the "tools" style = "fill:none; fill-opacity: 0.75;" Changing this to 1 fixes the problem.
Is there a reason for this 0.75 value? If not I suggest it gets changed so that the default references file has this value as 1.
Would this classify as a bug?
vellum
Bryce Harrington wrote:
Did this issue get fixed or entered in the bug tracker? I've not seen this behavior myself but am guessing it'd be a quick fix?
Would changing this entry at line 37 in preferences-skeleton.h be sufficient?
If so, I will do it...
" <group id="tools"" " style="fill:none;fill-opacity:0.75;"
Yes it would. We changed to fill-opacity 0.75 when we set the default colors for the basic shapes, because we thought the colors turned out better with a little alpha, but we didn't notice that it affected the text settings as well... Hmm...
I played with it a little bit, and while the colors do look good with a 3/4ths alpha, I'm wondering if for users unfamiliar with what alpha is, if that default might lead to some confusion, since their objects will "bleed" color through each other. So maybe setting default alpha to 1 would be the safest?
Bryce
Bryce Harrington wrote:
Yes it would. We changed to fill-opacity 0.75 when we set the default colors for the basic shapes, because we thought the colors turned out better with a little alpha, but we didn't notice that it affected the text settings as well... Hmm...
I played with it a little bit, and while the colors do look good with a 3/4ths alpha, I'm wondering if for users unfamiliar with what alpha is, if that default might lead to some confusion, since their objects will "bleed" color through each other. So maybe setting default alpha to 1 would be the safest?
You're right! And we should make everything grey for people who don't understand colours. And why do we have that spiral again?
Come on, people are sold on their first impressions, alpha makes things look a little more interesting. If anything is wrong, it is the fact that people seem to be unable to work out how to set the transparency - this is the bug, not whatever values we choose for a default.
njh
On Tue, 3 Feb 2004, Nathan Hurst wrote:
Bryce Harrington wrote:
Yes it would. We changed to fill-opacity 0.75 when we set the default colors for the basic shapes, because we thought the colors turned out better with a little alpha, but we didn't notice that it affected the text settings as well... Hmm...
I played with it a little bit, and while the colors do look good with a 3/4ths alpha, I'm wondering if for users unfamiliar with what alpha is, if that default might lead to some confusion, since their objects will "bleed" color through each other. So maybe setting default alpha to 1 would be the safest?
You're right! And we should make everything grey for people who don't understand colours. And why do we have that spiral again?
Come on, people are sold on their first impressions, alpha makes things look a little more interesting. If anything is wrong, it is the fact that people seem to be unable to work out how to set the transparency - this is the bug, not whatever values we choose for a default.
Well, the core issue here is that text should not be created with any alpha and should be solid.
Bryce
participants (6)
-
Bob Jamison -
Bryce Harrington -
Daniel Borgmann -
MenTaLguY -
Nathan Hurst -
vellum