Re: [Usability] UI design question
. * Create a new theme based on an existing theme - select theme, then click Duplicate... and type the name into the newly-created table row. * Open an existing theme - select theme, then click Open. * Edit current theme - open window, then click Edit (the current theme being selected by default). * Open last edited theme - select theme, then click Edit The catch is that this design really makes sense only if the window is a normal window, not a dialog -- because a dialog would expect a Cancel button, and that the buttons along the bottom would close the window, which you don't want for most of these buttons. (For example, often you'll want to click Edit... after clicking New... or Duplicate) Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_show_help and gtk_show_url
Sorry to come in here wildly late, but ... On Oct 8, 2007, at 8:34 AM, Shaun McCance wrote: On Sun, 2007-10-07 at 17:10 -0400, Havoc Pennington wrote: ... - in current GNOME, what are the right parameters to open a help file? (i.e. what values does gtk_help_show() need to open a gnome help file, such as document ID or anchor or whatever) http://library.gnome.org/devel/libgnome/stable/libgnome-gnome- help.html#gnome-help-display ... Some questions: - What sort of information does the Windows help system need? http://msdn2.microsoft.com/en-us/library/ms644704.aspx http://msdn2.microsoft.com/en-us/library/ms728718.aspx - What sort of information does the Mac help system need? ... http://urlx.org/apple.com/d50c3 Help buttons in Mac OS X (in bundled software, at least) usually don't open exact pages. Instead they open search results, in which the actual page the developer was thinking of is the first or second result. This is, I assume, because Apple are afraid of the software and the help getting out of sync. If a Help button linked directly to a page that had been renamed, or merged into another page, the help viewer would have to return a nasty error The help topic does not exist, contact your application vendor for an updated Help file à la Windows, and people would be put off trying to using the help ever again. I think that's a valid concern, but an annoying solution. I would rather that any updated API for opening a help page in Gnome had two compulsory parameters -- one for the page ID, and one for a fallback search string if Yelp can't find the page. That way the page-not-found error would only ever appear when debugging. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Usability] Correct Windows, KDE button order?
On Jan 6, 2007, at 4:13 AM, Christian Neumair wrote: Am Freitag, den 05.01.2007, 14:51 +0100 schrieb Sven Neumann: ... standard: [Reset] [Cancel] [OK] alternative: [Reset] [OK] [Cancel] I might be totally wrong here, but that's how we are arranging the buttons based on feedback from Windows users. I must admit that I also have no clue what the correct order is. I consulted MSDN but I couldn't find any interesting/relevant documents listing non-standard buttons, except some OK/Cancel/Apply examples [1]. The button order for dialogs in Windows Vista is described in the Dialog Boxes chapter of the Vista UX Guidelines http://msdn2.microsoft.com/en-us/library/aa511268.aspx#commitButtons: * Present the commit buttons in the following order: 1. OK/[Do it]/Yes 2. [Don't do it]/No 3. Cancel 4. Apply (if present) 5. Help (if present) * If you have many related commit buttons, consolidate them using split buttons. * Have a clear separation from commit buttons (which close the window) and all other command buttons (such as Advanced). The guidelines also specify that the tab order for these buttons should often be different from their visual order: the tab order can be summarized as in order of frequency, but with Cancel always last. http://msdn2.microsoft.com/en-us/library/aa511268.aspx#interaction ... So it looks like we should be able to adapt to the major desktop environments. Regarding the implementation of this in GTK+, we could do the following: We might eventually end up with optionally keeping around a whitelist of buttons to put on the very right and the very left in very a specific order, which we might store as an XSetting or widget style. Yes/No dialogs, or other dialogs that don't have exclusively buttons on the whitelists could be dealt with by additionally reversing the remaining buttons iff gtk-alternative-button is present. In Windows, using Yes/No dialogs is allowed: you can purposely use generic commit button labels to force users to read the main instructions and prevent hasty decisions. In Gnome and Mac OS, Yes/No dialogs should not be used, though their respective guidelines don't make this as explicit as they could. ... Proposed Windows whitelist (left): Help,Default,Revert ... As quoted above, the Vista guidelines put Help rightmost, not leftmost. If you're still game to attempt portability with Windows, remember that Windows Vista introduces some new challenges: * Secondary commands and navigation to other windows should often be links above the commit buttons, not commit buttons themselves. * Display of help should be available from a link under the commit buttons, not from a commit button itself. * Button labels should use sentence case, not title case as used in other platforms (and earlier versions of Windows). So if GTK (or Qt) are to handle this automatically they need to know, for each button: * whether it is (a) a primary command, (b) navigation or a secondary command, or (c) access to help; * if it is a secondary command or access to help, what its link label should be (because link labels should be more longer and more descriptive than equivalent button labels); * if it is a primary command, which of its words are capitalized because they are proper nouns (so that the label can be converted to sentence case without accidentally decapitalizing proper nouns); * if it is a primary command, a numeric value representing its frequency of use, so that tab order can be assigned appropriately. Have fun. ;-) -- Matthew Paul Thomas http://mpt.net.nz/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Still can't configure GTK for Gimp...
On Wed, 23 Oct 2002 [EMAIL PROTECTED] wrote: OK... So we're alledgedly checking in libjpeg... configure:13753: gcc -o conftest -g -O2 -Wall conftest.c -I/usr/local/lib -l iconv -lintl -liconv 5 But there's no -ljpeg in the actual gcc command. Something's on Did you create a './configure' yourself using autoconf? If so, the place Yes. to start looking would be a busticated install of autoconf and friends (I can't say for sure - first guess would be a failure to run aclocal). I'll check further. If it's the ./configure from a distribution tarball, it may be time to find the bell, the book, and the candles.. ;) From configure.in there is: dnl Test for libjpeg if test x$with_libjpeg != xno test -z $LIBJPEG; then AC_CHECK_LIB(jpeg, jpeg_destroy_decompress, jpeg_ok=yes, jpeg_ok=no AC_MSG_WARN(*** JPEG loader will not be built (JPEG library not found) *** )) if test $jpeg_ok = yes; then AC_MSG_CHECKING([for jpeglib.h]) AC_TRY_CPP( [#include stdio.h #undef PACKAGE #undef VERSION #undef HAVE_STDLIB_H include jpeglib.h], jpeg_ok=yes, jpeg_ok=no) AC_MSG_RESULT($jpeg_ok) if test $jpeg_ok = yes; then LIBJPEG='-ljpeg' AC_CHECK_LIB(jpeg, jpeg_simple_progression, AC_DEFINE(HAVE_PROGRESSIVE_JPEG), AC_MSG_WARN(JPEG library does not support progressive saving.)) else AC_MSG_WARN(*** JPEG loader will not be built (JPEG header file not found) ***) At the beginning is the first mention of $LIBJPEG in the configure.in script, so I'm not sure where $LIBJPEG is defined. Thanks, --Paul -- William J. Broad: The crux... is that the vast majority of the mass of the universe seems to be missing. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trying to configure/compile glib-2.0.6
I'm just able to get back to this.
On Wed, 9 Oct 2002, Owen Taylor wrote:
Paul Thomas [EMAIL PROTECTED] writes:
I got through my other hoops but while tyring to ./configure
on my Linux box (older install), the configure script gets
to this point then quits:
checking for working alloca.h... (cached) yes
checking for alloca... (cached) yes
checking for atexit... yes
checking for on_exit... yes
checking for char... yes
checking size of char... configure: error: cannot compute sizeof (char), 77
Anyone know what I might need to address to 'compute sizeof (char)'?
Look at config.log - you'll have some sort of compiler error
in there related to this.
Regards,
Owen
Yes, well there is in config.log:
configure:1: checking size of char
configure:12527: gcc -o conftest -g -O2 -Wall conftest.c -liconv
-lintl -lico
nv 5
configure:12527: $? = 0
configure:12527: ./conftest
./conftest: can't load library 'libiconv.so.2'
configure:12527: $? = 16
configure: program exited with status 16
configure: failed program was:
skip commented includes
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char)); }
skip commented includes
extern C
skip comment
int F77_DUMMY_MAIN() { return 1; }
skip comment
int
main ()
{
FILE *f = fopen (conftest.val, w);
if (! f)
exit (1);
if (((long) (sizeof (char))) 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, %ld\n, i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, %ld\n, i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, %lu\n, i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:12527: error: cannot compute sizeof (char), 77
I don't know why:
configure:12527: ./conftest
./conftest: can't load library 'libiconv.so.2'
is happening as 'libiconv.so.2' is right here:
/usr/local/lib/libiconv.so.2
freshly installed from:
/var/local/src/libiconv-1.8/
Any comments appreciated.
Thanks,
--Paul
--
William J. Broad: The crux... is that the vast majority of the mass
of the universe seems to be missing.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trying to configure/compile glib-2.0.6
On Mon, 14 Oct 2002, Owen Taylor wrote: Paul Thomas [EMAIL PROTECTED] writes: I'm just able to get back to this. On Wed, 9 Oct 2002, Owen Taylor wrote: Paul Thomas [EMAIL PROTECTED] writes: to this point then quits: I don't know why: configure:12527: ./conftest ./conftest: can't load library 'libiconv.so.2' Two possibilities: 1) /usr/local/lib isn't in /etc/ld.so.conf 2) You haven't run ldconfig It was possibility number 2! For some reason I presumed that was all taken care of when I installed libiconv-1.8. Thanks for the help folks! --Paul -- William J. Broad: The crux... is that the vast majority of the mass of the universe seems to be missing. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
GTK: Checks for JPEG loader failed
Heh, well I have made some progress on to configuring GTK itself now but, stuck again Configure bombs out with a 'Checks for JPEG loader failed'. To be sure, I went and downloaded the jpeg source and installed it, it's all there but gtk isn't finding the jpeg library. Config.log shows: configure:13720: checking for jpeg_destroy_decompress in -ljpeg configure:13720: gcc -o conftest -g -O2 -Wall conftest.c -ljpeg -liconv -lin tl -liconv 5 /tmp/cca130841.o: In function `main': /usr/local/src/gtk+-2.0.6/configure:13738: undefined reference to `jpeg_destroy_decompress' configure:13720: $? = 1 configure: failed program was: #line 13720 configure #include confdefs.h Comments appreciated. Thanks, --Paul -- William J. Broad: The crux... is that the vast majority of the mass of the universe seems to be missing. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Trying to configure/compile glib-2.0.6
Hi, I got through my other hoops but while tyring to ./configure on my Linux box (older install), the configure script gets to this point then quits: checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for atexit... yes checking for on_exit... yes checking for char... yes checking size of char... configure: error: cannot compute sizeof (char), 77 Anyone know what I might need to address to 'compute sizeof (char)'? Thanks, --Paul -- William J. Broad: The crux... is that the vast majority of the mass of the universe seems to be missing. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Can't configure
Hi, I'm trying to compile glib-2.0.6 and get the following error: checking for iconv_open... no checking for libiconv_open in -liconv... no checking for iconv_open in -liconv... no configure: error: *** No iconv() implementation found in C library or libiconv What do I need to update here? Thanks, --Paul -- William J. Broad: The crux... is that the vast majority of the mass of the universe seems to be missing. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
