Tim Janik wrote:
> On Sat, 9 Dec 2006, Bill Haneman wrote:
>
>> Hi All;
>>
>> As I understand it, the proposal below would probably break gail
>> unless/until we roll it into gtk+.
>
> can you please elaborate why this should be the case?
> basically, the pro
Hi All;
As I understand it, the proposal below would probably break gail
unless/until we roll it into gtk+. While gail currently uses public
gtk+ API to fulfill the ATK implementations, it relies rather heavily on
the details of the existing implementation.
I think this would force the issue
Hi:
>
>
>> - homogeneous or consistent test output might be desirable in some contexts.
>>
>
> Yes, it is an important point when thinking about a continuous
> integration tool for Gnome. If tests for all modules in Gnome agree on a
> common output format, then that data can be collected, p
One of the big challenges for a gtk+ canvas has to do with
accessibility. If we build a gtkcanvas that is nice to use (and
therefore gets widely adopted), it also has to expose all the
appropriate ATK information. Otherwise, we'll be eroding gtk+
accessibility, and creating obstacles to deplo
Hi;
The new serialize/deserialize API for GtkTextBuffer looks to be very
useful to accessibility among other things. I am currently using it to
implement AtkStreamableContent, an interface which allows objects with
streamable backing data (for instance images, HTML widgets, text
containers...) to
On Tue, 2006-02-07 at 11:36, michael meeks wrote:
> Hi there,... Bill - I'm slightly amazed we havn't
> seen this before - whatsup there ? :-)
Well, I suspect that the Gnome HEAD a11y bits haven't gotten much
exercise until lately. Fortunately that's changing, at least on the Sun
end of things -
This looks great, but I don't see anything in the print context relating to the use of
"themed" rendering.
Should it be somewhere other than the print context?
Something like this:
gboolean egg_print_context_get_override_document_colors ()
GdkColor egg_print_context_get_text_foreground ()
GdkC
Jonathan Blandford wrote:
On Tue, 2006-01-24 at 14:48 +, Calum Benson wrote:
Yes... gnome-print :) Or at least, it used to:
http://bugzilla.gnome.org/show_bug.cgi?id=96802
http://bugzilla.gnome.org/show_bug.cgi?id=158012
so if it doesn't any more, I guess we've just entered Regressio
Alexander Larsson wrote:
On Mon, 2006-01-23 at 11:48 +, Bill Haneman wrote:
Alexander Larsson wrote:
Nobody is going to render their paper output with theme colors, that
just isn't the way apps are set up (i.e. the printing output is not
coupled to the current on-screen set
BTW
In case anyone reading is unfamiliar with what is meant by "WYSIWYG",
which I have used several times, it means "What You See Is What You Get".
Print preview is of course "normally" supposed to reflect visually what
will be on paper. For some user populations this is not desirable (some
Alexander Larsson wrote:
On Fri, 2006-01-20 at 12:36 +, Bill Haneman wrote:
Also, for theming, it should be possible to preview the document in a
non-WYSIWYG mode. I know may seem like a mis-feature to some, but for
people with certain vision disorders, it's vital that even
Hi everyone;
I have a couple of thoughts/reminders. The printing dialog ought to be
checked with at-poke and event-listener-test (better yet, tested with
gnopernicus or orca) to ensure that it speaks appropriate content when
navigated. It would also be a good time to ensure that the new dial
(federico)
API freeze for GNOME 2.14 is approaching quickly. Can we please back
out GObject floating references soon?
(timj)
no, there really is no point in that. even if we were to do that, we
couldn't hold off floating references for non-GtkObjects but GObjects
anyway. the results
OK, I understand that nobody wants to spend time fixing code that's only
exercised on obsolete hardware. But it's worth remembering that one of
the key areas of interest/growth for Gnome is the low-cost and used
hardware community in the developing world, etc. As long as we're still
pitching
Thanks Owen, I think I'm on the same page now.
:-)
The gnome-vfs file chooser backend -- the one that is default in a GNOME
desktop -- already incrementally grows the file lists.
Regards,
Owen
__
Federico Mena Quintero wrote:
On Fri, 2005-12-09 at 17:47 +, Bill Haneman wrote:
One thing that isn't clear to me, from my admittedly superficial reading
of the proposals, is how the need to notify clients of changes to the
file chooser list will be implemented.
For accessibilit
One thing that isn't clear to me, from my admittedly superficial reading
of the proposals, is how the need to notify clients of changes to the
file chooser list will be implemented.
For accessibility, we will need to fire notifications via ATK of all
changes to the file chooser list. This mea
Alexander Larsson said...
In fact, I think its more important to have a simple canvas like that
than a really powerful flexible thing to be used for diagram editors and
powerpoint apps for the simple reason that I'm not at all sure such apps
would use a generic canvas. Each major app is gonna ha
Hi:
ATK has branched for gnome-2.12 (finally). New API has been added to
HEAD. This includes a handful of new translatable strings.
thanks
Bill
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-dev
A number of interesting issues get raised when one talks about scalable
canvases, especially when the complexity of the rendered content changes
with 'zoom level'.
It may be important to distinguish between scaled-canvas-size, and
notional "zoom level". For instance, a user with poor vision m
Matthias Clasen wrote:
...
5) There is an implied focus problem; does the bubble steal focus when
it demands attention? Almost certainly it shouldn't, but otherwise how
does the screenreader or magnifier user notice it? We may need some
kind of API for this - but the WM hints for urgency a
Hi:
Nice feature; I can see a lot of accessibility questions related to it
though.
1) First, yes, allowing stock icons may be the best way to make these
theme-compatible, which of course is vital.
2) Notifications are probably critical to accessibility;
3) If they react to the mouse, they ne
...
I see 3 benefits in having more stock items:
- if 2 apps are open using the same icon the memory can be shared
- a developer won't have to look far for a icon
- HIG will be better because you use the same icons through all the
apps.
Another benefit is that this would help ensure that such
Owen Taylor wrote:
On Tue, 2005-06-21 at 07:19 -0400, Mike Emmel wrote:
No atk ?
Does the current released version work or should it be from cvs ?
Current released should be fine as far as I know. I haven't
really tracked what's going on in CVS for ATK.
1.10.1 should be fine
ht
On my system, upgrading to libtool 1.5.14 solved the problem.
- Bill
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Soeren Sandmann wrote:
Bill Haneman <[EMAIL PROTECTED]> writes:
The ONLY time that an application should choose a specific color (or
even a specific value, i.e. 'black' or 'white') is when "red means
RED", i.e. if the application is a painting application,
Federico Mena Quintero <[EMAIL PROTECTED]> writes:
Having things like your proposed GTK_PALETTE_RED doesn't make much
sense; if you want a specific color, just use it from your app:
I am not sure I agree. Red is not just red. It is not uncommon for
applications to just need a few colors to ma
JP Rosevear wrote:...
So to extend the current notion of SELECTED, PRELIGHT, FG, BG, BASE, TEXT, we need other style names that indicate the context in which a color is to be used, but not its hue or value.
Something like "HIGHLIGHT" might be nice, useful in Evolution for things
like outlining
typedef enum {
GTK_PALETTE_DARK,
GTK_PALETTE_SEMI_DARK,
GTK_PALETTE_MID,
GTK_PALETTE_SEMI_LIGHT,
GTK_PALETTE_LIGHT,
maybe, but not appropriate to 'inverse' themes, for instance...
GTK_PALETTE_RED
GTK_PALETTE_PURPLE
GTK_PALETTE_BLUE...
No, definitely bad ;-)
because this would encour
Gustavo said:
2. Your canvas looks excessively complex to me. Are you sure we need
canvas item model/renderer separation? I think you need it if:
a) You want to store data that is specific for per item-view
pair;
Example: some caching of pixel coordinates, or something l
30 matches
Mail list logo
