Re: Trouble with inverted tree view background (arabic version) - bug correction submition
Hi Behdad,
I just submited bug at bugzilla (Ref 318781).
Don't hesitate to tell me if i missed something...
Eric
Le jeudi 13 octobre 2005 à 06:17 -0400, Behdad Esfahbod a écrit :
> Hi Eric,
>
> Thanks for the note. Indeed it's a bug, and your solutions
> generally looks right. Please file a bug at the bugzilla
> (http://bugzilla.gnome.org/) You need to create an account first
> if you do not have already. Then attach the patch to the bug,
> and also attach screenshots of a test program before and after
> the patch, and attach the test program too. Please add me to the
> CC field using the gnome at behdad dot org address.
>
> This way you can be sure that the proper fix will be in the next
> version of gtk+ :).
>
> Thanks again
> behdad
>
>
>
> On Wed, 12 Oct 2005, Eric Cazeaux wrote:
>
> > Hi,
> >
> > When i fill cell on GtkTreeView with a background color, all work fine in
> > "normal" direction, but in inverted mode (eg Arabic), background overlap
> > sibling cells...
> > I think i have found the source of the problem...
> >
> > In function gtk_tree_view_column_cell_process_action of
> > gtk/gtktreeviewcolumn.c
> >
> > The variable depth is used to compute offset between background and cell
> > border (taking into account horizontal_separator).
> > I think that this calculus must be different in inverted mode (so 'rtl'
> > variable value is true).
> >
> > Well the original calculus is :
> >
> > depth = real_cell_area.x - real_background_area.x -
> > horizontal_separator/2;
> >
> > Now my modification is :
> >
> > if (rtl)
> > {
> > depth = real_background_area.width - real_cell_area.width -
> > horizontal_separator/2;
> > }
> > else
> > {
> > depth = real_cell_area.x - real_background_area.x -
> > horizontal_separator/2;
> > }
> >
> >
> > And now treeview with background filled work perfectly!
> > So now, how can i submit this modification...to be took account for a
> > later release of gtk?
> >
> >
> > Eric
> >
> >
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
>
> --behdad
> http://behdad.org/
>
> "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
> -- Dan Bern, "New American Language"
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
Kalle Vahlman writes: > I calculate that it takes more time to figure out what header provides > this and that every time you decide to add a feature which will need a > header not included yet than to just use the toplevels and face the > compilation time penalty. I agree. And few developers bother removing headers that have became unneeded after (re)moving code from a source file. Presumably, most often developers just copy-paste the list of #includes from some other random source file, instead of really making an effort to use just a miminal set of headers. This certainly seems to be true in Evolution. I know for sure that lots of Evo (including E-D-s) source files used to include headers like or , for instance, even if no corresponding functionality was used in the source files in question. This doesn't really give credibility to a claim that the set of included gtk*.h headers in Evo source files would be carefully hand-optimized. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
2005/10/13, Mikael Hallendal <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > I meant things that matter. > > > > (compile time is not a signifcant metric for software quality in my book) > > What do you mean? I mean I care about things visible to the user, not the developer (alhough I *am* making stuff for the developer...). > By including only the headers you need can substantially affect the time > you spend waiting for compilation, especially in a large application > such as Evolution. Users won't be waiting for compilation to finish. They won't be compiling (at least I hope not). Developers will, but unless you are developing the actual software, it should be a infrequent one-time action. And if you are developing the actual software, you will be compiling only the modifications, which means it won't take too long anyway so the gain is smaller. > That time can of course be used to improve you application so, in a way > it can effect the quality of a code but not necessary. If indeed compiling from scratch all the time, sure, it can take a while to compile. But I just don't think it is significant enough to actually make a difference. I say this when developing on a mobile Celeron @700MHz and little over 300 megs of RAM and a sluggish harddisk, so it *MUST* be ok for other devs too ;) If your application takes forever to compile, it could be that it's not the compilers fault... ];-) > So I would say that's a good reason for not doing it. I calculate that it takes more time to figure out what header provides this and that every time you decide to add a feature which will need a header not included yet than to just use the toplevels and face the compilation time penalty. But I guess it comes down to ways of developing and other matters of taste (which are less than useful subjects for discussion, unless having a beer while at it). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for GTK+ advanced formatted entry and spinner
The problem with the GtkTextBuffer as I see it is that it will take alot of coding to implement a formatted entery and especially a formatted spinner. Just to make it clear, an (not ver good, but somewhat explanatory) example for a formatted spinner can be seen in the MS-Windows Date and Time Properties window (double click the task-bar clock). Using a GtkTextBuffer it would require to insert several UI elements into the buffer, and connect them somehow. Another problem it will bring is that formatted entry and spinbutton should be a simple, one-liner element, not a buffer. It should be used to assist the user in handling well-formed small pieces of data, like date, time, ip address, and other, user defined data (I am developing a system that include geographic elements, so I could also use it for Lat/Long element, and several grid elements, each with a different format). Perhaps there should be another widgets, like there are GtkEntry and GtkCompletionEntry, there will also be GtkFormattedEntry and GtkFormattedSpinner. Please let me know what you think, and if there is a different place I should post this idea. Thanks, Itai. P.S. Hans, sorry for the double post, I'm still getting used to this mailing-list conversation thing and how it works... :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
On Wed, 12 Oct 2005 14:55:32 -0400, Dan Winship wrote: > Evolution switched from using the main headers to using specific headers a > few years ago to speed up the compile time (substantially). I think some > other apps do this as well. These days the opposite will be true - you can precompile the GTK+ headers all in one go and include them as a binary header. I've tried this and it works well. One caveat is that you can only include one binary header. But, you can make a custom header file that simply includes gtk.h, and any other headers a particular part of your program needs and precompile that. The savings can be significant (on the order of 30-40% speedup in my own tests). thanks -mike ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
Kalle Vahlman wrote: > 2005/10/12, Dan Winship <[EMAIL PROTECTED]>: > >>Kalle Vahlman wrote: >> >>>Is there any reason to do otherwise? >> >>Evolution switched from using the main headers to using specific headers >>a few years ago to speed up the compile time (substantially). I think >>some other apps do this as well. > > I meant things that matter. > > (compile time is not a signifcant metric for software quality in my book) What do you mean? By including only the headers you need can substantially affect the time you spend waiting for compilation, especially in a large application such as Evolution. That time can of course be used to improve you application so, in a way it can effect the quality of a code but not necessary. So I would say that's a good reason for not doing it. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Trouble with inverted tree view background (arabic version) - bug correction submition
Hi Eric,
Thanks for the note. Indeed it's a bug, and your solutions
generally looks right. Please file a bug at the bugzilla
(http://bugzilla.gnome.org/) You need to create an account first
if you do not have already. Then attach the patch to the bug,
and also attach screenshots of a test program before and after
the patch, and attach the test program too. Please add me to the
CC field using the gnome at behdad dot org address.
This way you can be sure that the proper fix will be in the next
version of gtk+ :).
Thanks again
behdad
On Wed, 12 Oct 2005, Eric Cazeaux wrote:
> Hi,
>
> When i fill cell on GtkTreeView with a background color, all work fine in
> "normal" direction, but in inverted mode (eg Arabic), background overlap
> sibling cells...
> I think i have found the source of the problem...
>
> In function gtk_tree_view_column_cell_process_action of
> gtk/gtktreeviewcolumn.c
>
> The variable depth is used to compute offset between background and cell
> border (taking into account horizontal_separator).
> I think that this calculus must be different in inverted mode (so 'rtl'
> variable value is true).
>
> Well the original calculus is :
>
> depth = real_cell_area.x - real_background_area.x -
> horizontal_separator/2;
>
> Now my modification is :
>
> if (rtl)
> {
> depth = real_background_area.width - real_cell_area.width -
> horizontal_separator/2;
> }
> else
> {
> depth = real_cell_area.x - real_background_area.x -
> horizontal_separator/2;
> }
>
>
> And now treeview with background filled work perfectly!
> So now, how can i submit this modification...to be took account for a
> later release of gtk?
>
>
> Eric
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
--behdad
http://behdad.org/
"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
2005/10/12, Dan Winship <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > 2005/10/12, Owen Taylor <[EMAIL PROTECTED]>: > >> But we'd prefer that people included the main headers > >> gtk/gtk.h gdk/gdk.h gdk-pixbuf/gdk-pixbuf.h, etc. > > ... > > > Is there any reason to do otherwise? > > Evolution switched from using the main headers to using specific headers > a few years ago to speed up the compile time (substantially). I think > some other apps do this as well. I meant things that matter. (compile time is not a signifcant metric for software quality in my book) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
