Re: Website proposal for usability
WOW. Well done. I really the new design. Separating out the permenant information in a side box from the on going information makes it really nice. Great to see the amount of testing you did on different platforms as well!. -Ghee P.S. Though I am not sure if this is the mailing list to post suggestion of changes for website. I hope the relevant person will get in touch with you. On 08/ 9/10 10:54 PM, Devin Samarin wrote: I posted this on Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=626380) and I was recommended by Martyn to post the details here. I was browsing around gtk.org and I thought that it could use some adjustments. So I downloaded the web files with git and made some changes. I attached some screenshots and example file on Bugzilla (the design changed a little since then), but if my computer is up, you can see it at http://eboyjr.homelinux.org:8080/gtk/ . I made the width of the content area wider and added either columns or a sidebar for pages that needed it. Having columns makes it easier to read by making it so that you don't have to scroll for everything. For styling, I added some rounded corners with CSS for some of the elements. For all of the pages, I made the HTML more semantic by removing replacing some of thetables with ul's. I changed the color of the headers to the shade of blue. For the features page, I separated each section into blocks and added some pictures to spice it up. For the commerce (success stories) page, I did the same thing so that it is easier to read, and looks nicer. I made a template.php file which has the outer content of the HTML pages, so as a consequence, the pages' extension is changed from .html to .php. I think it's better so that for some changes, you wont need to edit every single page of the site. So with this design, some external links might need to be updated unless PHP can be run with the .html extension. Since it uses PHP, I made it easy to update changes to the tables. Specifically the language bindings page. There is a PHP array that stores all the information about the bindings and then formats it into a table automatically. I attached that file so you can see it. I have tested it so far in: * Internet Explorer 6, 7, 8 Everything works except the rounded corners, except for the header which is a single image so that works. Personally I don't think rounded corners are necessary, but if you think I should hack them in I'll do it * Firefox 2 Everything is messed up. This is because I am using HTML5 elements... I made the CSS not specific to tag names, so changingarticle todiv class=whatever would make it work fine. This also means that in IE, JavaScript must be enabled. I thought I'd try something new but HTML5 just causes pains. So I'll change them todivs. * Firefox 2 and 3 on Windows and Firefox 3 on Linux * Safari 3 and 4 on Mac * Google Chrome 3 and 5(beta) on Windows The design is not complete and still requires changes to be compatible with all browsers, but once it's done I really think it would make gtk.org much more usable. I am open to any suggestions. Devin Samarineboyj...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ print preview
Carlos Garcia Campos wrote: El mar, 19-05-2009 a las 07:46 +0200, Sven Neumann escribió: Hi, On Mon, 2009-05-18 at 15:06 +0200, Carlos Garcia Campos wrote: I've realized that print preview doesn't work as I thought, and I'm bit confused. An application open the print dialog by using GtkPrintOperation, then the user clicks on preview and a pdf file is generated to be used by a previewer. Such a file is passed to evince together with the print settings needed to print the file. The print dialog is closed, so we need to be able to print the document from the previewer. I don't understand why the previewer should be used to print the document. You may be right that this is what the authors of the GTK+ print dialog intended, but it is certainly an odd concept. I find it very confusing that the Print dialog closes when I hit the Preview button. Wouldn't it be better if it stayed open so that I can make adjustments if the preview turns out wrong and hit the Print button when I am satisfied with the preview? Yes, I agree, this was already discussed in this list before[1], though. Leaving the print dialog open, would also allow to change again the print settings if you are not happy with the preview results or just want to try other settings. Current flow is quite annoying in such cases, since you have to close the previewer and start the whole process again. Yes. If you want to do this, then evince can not be used as a previewer, since it is a different process. Why can't gtk+ provide the preview itself, I thought I read some discussion of having a Preview widget here. I also think that having a Print Preview dialog available while no printer is selected meant it is hard for create correct printer settings accordingly. -Ghee [1] http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00044.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Embedded page setup dialog in the print dialog
Marek Kasik wrote: Hi all, I'm working on a fix of the bug #551409. I would like to add a Paper size combo box and an Orientation combo box to the Page setup page. This combo boxes would be optional (depending on call of gtk_print_operation_embed_page_setup_dialog()). I would also change layout preview on Page setup page. Size of the layout preview should be proportional to selected paper size and the size should be shown. I've already done something in this, you can have a look at it at http://mkasik.fedorapeople.org/embedded_page_setup_dialog/screenshots/. Nice work :). I think even having to create a need for localization (.i.e. mm) is worthwhile.) How would that look though when you have to deal with multiple pages per side? -Ghee What do you think about this? Regards Marek ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? -Ghee Vincent Untz wrote: Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit : I don't see any way around discussing this with the GTK+ team before taking any decisions. I was hoping this would be discussed on gtk-devel-list and that a decision would have been taken there :/ If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Hrm, well, that's definitely late for smoketesting... Vincent ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
Cody Russell wrote: I was thinking that it would be nice if there was an integrated print preview widget in GTK+, that would be available cross-platform and wanted to check with people here before I commit much time to this. Right now we're spawning another process to do this, and I think an integrated widget would be much nicer. Thoughts? Will be most interested in your idea to achieve cross-platform (which I presume are windows, MacOS, Linux/Unix), though the latter are pretty much based on a layer above X. Definitely a+1 here. -Ghee ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-builder-convert
Hi, As we are preparing in integration of GNOME 2.20 for Solaris and came across this new binary, gtk-builder-convert in the gtk+-2.0 version 2.11.6. What is the interface stability of this program? By this I mean will it be supported and remained around much the same way as gdk-pixbuf-csource ? Thanks, -Ghee ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Gustavo J. A. M. Carneiro wrote:
On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
Joseph Sacco wrote:
The currently available version of pygtk is the stable branch. I would
expect the development branchof pygtk to adapt.
I'm ready to adapt but only if the general consent is that API changes
are okay.
My personal opinion is that the API shouldn't be allowed to change, once
an API is added it should stay stable until the major version is bumped
(3.0 in the case of gtk+).
I'm 100% with Johan on this one. Gtk+ 2.11.x broke API and ABI.
The real test for this is if some one who has developed a GTK+ based
on GNOME 2.0
and now copy over the binary to GNOME 2.20, will it run?
If not, it is breaking ABI. Breaking ABI at GTK+ is not good.
You can fix the API by recompiling, but you can fix ABI if the user
doesn't have the code
to recompile or too complex to recompile which is likely to happen in
the real world.
-Ghee
Before 2.11.x, the structure is:
struct _GtkTooltips
{
GtkObject parent_instance;
GtkWidget *tip_window;
GtkWidget *tip_label;
GtkTooltipsData *active_tips_data;
GList *tips_data_list;
guint delay : 30;
guint enabled : 1;
guint have_grab : 1;
guint use_sticky_delay : 1;
gint timer_tag;
GTimeVal last_popdown;
};
None of these fields is marked private, therefore they are public.
Public fields are part of the API and cannot be changed as per GNOME
Developer Platform. Probably there is a way to introduce the new
tooltips without having to break the old tooltips API!
Just because pygtk _can_ adapt doesn't mean that it _should_.
In fact there are at least a couple of other changes in gtk+ 2.11.x that
break the API; we should really be more careful about these things...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10.7 released
Or the above claim should be reformulated as: * for gtk+2.8.20 there are no known to developers occurences of memory leaks; * gtk+2.10.* is effectively a developmnet release, so expect memory leaks and stay away from it for production code. I am asking these particular questions because of the 387170 Fairly large leak in gtk+ 360350 leak in gtk_radio_button_focus 362439 gtkicontheme::pixbuf_supports_svg leaks GList 364514 gtk leaks GDI objects on the win32 classic look and feel 364868 GDI resource leak in GtkStatusIcon on win32 370395 leak in gtk_rc_parse_icon_source 382314 gtkpagesetup leaks when setting new paper size 389194 mem leaks in gtkpagesetupunixdialog These two bugs are printing related which is a new feature in 2.10. 348108 Refleaks in gtk-demo Great patch in the sense that gtk-demo is probably the way most people would learn about GTK+ programming at the beginning, proper coding sample helps ..:) -Ghee ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
