Re: Updating the icon cache (GNOME Goals)
Federico Mena Quintero wrote: Hi, I just saw this http://live.gnome.org/GnomeGoals/AppIcon about making apps update the GTK+ icon cache during make install. This would be fine in a tarball-only world, but I wonder if distros will just end up patching out that part of Makefiles, and calling gtk-update-icon-cache on their own. For example, in openSUSE we update the icon cache separately from package installation, with the idea that the cache will only be updated once even if many packages are installed. (The really right way may be to use an RPM %posttrans - no idea if that works.) Yes, %posttrans is the best way to do it (on upgrade or new installation). On package removal, you need to call it in %postun (or %postuntrans) conditionally as well to remove obsolete entries. I see very important drawbacks of doing it on per-package basis: - Also KDE/Qt/XFCE packages need to call gtk-update-icon-cache to display correctly in GNOME menu. - Increases time to install (called once per package). Better solution would be trigger triggered by virtual symbol. I proposed it longer time in past, but I am not sure, whether it is already implemented. Then I see no problem to create proper RPM symbol (e. g. has_xdg_icon) in autoreqprov script. It is still not ideal, we would need script triggered once per transaction, not once per package. %posttrans works with following limitations: - Not implemented in older versions of RPM. - Less old RPM call %posttrans even for rpm --test, so there are needed hacks to work-aroud this problem. - AFAIK Requires(posttrans) is not defined, but in most/all cases Requires(post) will do what needed. - %preuntrans does not exist (not useful here, but would be very useful for gconf scriptlets, which now need ugly hacks to work correctly). So, do we really need this in tarballs? Yes. It is intended for people, who install package manually directly to live system. And absolutelly ideal would be a new auto* standard: If package needs special action for installation/upgrade/removal, specially named file containing these commands will be created. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Claudio Saavedra wrote: Before I start filing bug reports I would like to know, if you (GNOME) still use the Application category, that I can find in almost all .desktop files you ship. The category AFAIK is some old relict of GNOME = 2.4 and not a valid nor registered category following the current freedesktop.org specification, which is AFAIK supported since 2.4 - 2.8. Now GNOME reached 2.18 and I can still find this category. So is it still used somewhere? If yes, is it necessary? If no: How do you handle muss bug-filing normally? There was a GNOME Goal about removing the Application category shortly before 2.18 was released. Most probably, not all the applications in the release set fixed this right in time. For SuSE it is: https://bugzilla.novell.com/show_bug.cgi?id=254654 I already removed Application from all SuSE patches and spec files (i. e. places where SuSE explicitly added it). I plan to reopen it after a year or so and patch remaining applications, where upstream did not fix it. It would be enough to make this error fatal in desktop-file-validate. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Vincent Untz wrote: Le jeudi 21 juin 2007, à 11:14 +0200, Stanislav Brabec a écrit : I already removed Application from all SuSE patches and spec files (i. e. places where SuSE explicitly added it). I plan to reopen it after a year or so and patch remaining applications, where upstream did not fix it. It would be enough to make this error fatal in desktop-file-validate. It can easily be done, but I didn't want to do too soon, since really a lot of modules were broken. Another option is probably to add a --no-deprecate argument to desktop-file-validate, which changes deprecation warnings into errors. Do you want to open a bug in fdo bugzilla? :-) Let's wait some time for upstream fixes. Otherwise it will break a lot of packages. In time of last check, about 40% of all desktop files have had Application in Categories. After a year or so we can fix the rest. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sticky Windows
Kalle Vahlman wrote: I remember seeing an equivalent feature in that modern window manager called twm. Only in that it wasn't restricted to the screen edges, it was anywhere on the desktop area! I remember this feature from my AmigaOS 15 years ago. But AmigaOS implemented it better allowing to send key events to minimized applications: Simply putting mouse pointer over the icon and entering commands into minimized terminal or press shortcuts for minimized editor was really cool. It is definitely missing in GNOME - both minimized windows as desktop icons (as an alternative to windows list) and minimized window events. From usability experience, Sticky windows and Iconified windows are different from Windows Lists, because it exercises different type of human perception. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-vfs-2.17.91 hard dependency on gnome-mime-data
Alexander Larsson píše v St 28. 02. 2007 v 09:30 +0100: On Tue, 2007-02-27 at 17:54 +0100, Fryderyk Dziarmagowski wrote: --- Bastien Nocera [EMAIL PROTECTED] wrote: No, it isn't only a run-time dep, or at least shouldn't be. The gnome-mime-data doesn't have to be in the same place as the libraries you're installing, and gnome-vfs should still be able to find the files. You can safely remove PKG check from configure and build g-vfs without smallest problems. You can even run all major GNOME apps without it. Forcing people to use something that is not needed it's IMO wrong. You can do all sorts of shit manually if you want. That doesn't change a single thing. We enforce backwards compatibility. Maybe some third party app still use the gnome-vfs APIs that use the old mime data. We don't just break it to save a few bytes. Then please reopen Bugzilla for gnome-mime-data. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-vfs-2.17.91 hard dependency on gnome-mime-data
Hallo. It seems, that gnome-vfs-2.17.91 contains hard dependency on discontinued gnome-mime-data. I see no reason for it. Does anybody know? configure.in: PKG_CHECK_MODULES(... gnome-mime-data-2.0 ...) Related bug: http://bugzilla.gnome.org/show_bug.cgi?id=336952 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-vfs-2.17.91 hard dependency on gnome-mime-data
Bastien Nocera píše v Út 27. 02. 2007 v 14:33 +: On Tue, 2007-02-27 at 12:52 +0100, Stanislav Brabec wrote: Hallo. It seems, that gnome-vfs-2.17.91 contains hard dependency on discontinued gnome-mime-data. I see no reason for it. Does anybody know? configure.in: PKG_CHECK_MODULES(... gnome-mime-data-2.0 ...) Backwards compatibility. There are deprecated functions in gnome-vfs (which you wouldn't see with an all updated application base) which rely on gnome-mime-data. Most other GNOME applications don't provide application-registry and GNOME mime-info any more, I doubt it will do anything useful even with gnome-mime-data. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: get rid static libraries or fix them
Tristan Van Berkom wrote: Hi, Currently I dont see anything wrong with the state of affairs at all. I see: Many GNOME *.pc files are broken, because Libs.private required for static linking are missing. Default configure options are inconsistent, causing even more problems. Just because you havent built gnome-keyring or gtk+ statically I built all these libraries with the default configure options. You have to explicitly use ./configure --enable-static to build static gtk+. Using ./configure, you will not get static library. For consistency, ./configure for libgnome should not provide static library, too, or at least it must be able to produce working static library stuff (correct .pc file) while using default configure options. there is a program that I link glib statically and will continue to do so since the risk is little to none for that case... ... If you don't use gmodule. pkg-config does the same. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: get rid static libraries or fix them
James Henstridge wrote: If you find things missing from Requires.private or Libs.private for a package, please report bugs. See http://bugzilla.gnome.org/show_bug.cgi?id=405352#c2 However my guess, where private libraries are missing, may be incorrect. Another problem with static libraries is a problem with linking with by default shared only (for good reason) libgtk-x11-2.0.so, which implies need for: -Wl,-Bdynamic -lgtk-x11-2.0 -Wl,-Bstatic instead of simple: -lgtk-x11-2.0 This may be considered as a problem of gtk: pkg-config --static --libs gtk+-2.0 will not work, unless you compile static gtk+ and pango libraries by explicit recompilation with --enable-static. So if package disable static library by AM_DISABLE_STATIC, the *.pc it should care about -Wl,-Bdynamic and -Wl,-Bstatic. It seems, that pkg-config does not support it, so I consider it as a lack of feature in pkg-config. I have just reported it as: https://bugs.freedesktop.org/show_bug.cgi?id=9917 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
get rid static libraries or fix them
Hallo. I have just got a bug report saying, that static instances of GNOME libraries are not useful. I wanted to oppose, so I have tried to link gnome-hello statically. It failed and I have discovered many bugs. It seems, that nobody ever tried to use static libraries, otherwise these bugs would be discovered many years ago. So we should find all lower mentioned (and probably many unmentioned) static issues and fix them or we should disable static libraries for the whole platform. In current state, it's only a waste of disk space. What is your opinion? http://bugzilla.gnome.org/show_bug.cgi?id=405352 gcc -Wall gnome-hello.c -o gnome-hello -static $(pkg-config libgnomeui-2.0 --static --libs ; pkg-config libgnomeui-2.0 --cflags) /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lgnome-keyring collect2: ld returned 1 exit status gcc -Wall gtk-hello.c -o gtk-hello -static $(pkg-config gtk+-2.0 --static --libs ; pkg-config gtk+-2.0 --cflags) /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lgtk-x11-2.0 collect2: ld returned 1 exit status Trying manually it discovered tons of missing dependencies as undefined symbols. At least these private libraries are missing somewhere (in braces the most probable candidate): libesd (libgnome), libaudiofile (libgnome), libXrender (cairo), libxml2 (libfontconfig), libXau (libX11), libXdmcp (libbonobo), libORBitCosNaming-2 (libbonobo), libdbus-1 (libgnome-vfs-2, maybe also libdbus-glib-1). Packages atk, gtk+, glib, gnome-keyring, pango don't provide any static libraries - they use AM_DISABLE_STATIC. It implies need for -Wl,-Bstatic and -Wl,-Bdynamic to static pkgconfig linking options for all references to libraries from these packages. And finally it is required to solve fragility of loading: - gnome-vfs modules from statically linked binaries (probably by disabling of static linking of gnome-vfs). Following optional private libraries may be needed for static libgnomevfs-2: libdns_sd or libavahi, libssl or libgnutls. - GConf backends from statically linked binaries (probably by disabling of static linking of GConf). And if we decide to re-enable building of static instances of atk, gtk+, glib, gnome-keyring, pango, then we also need to find a proper fix for fragility of loading of gtk modules, pango modules and gmodule stuff. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop Session Presence Manager
Ross Burton wrote: On Tue, 2007-01-23 at 18:11 +, Brian Nitz wrote: I was thinking about when you might want use this. Let's say you're inside a tight loop in an applet or gdesklet and you want to check if anyone is watching before you do the last bit of graphics scaling, 3D blending, shading and anti-aliasing before updating the screen every 50 microseconds ;-) Which would be faster, asking the galaga service to ask if I'm here or check a presence gconf key (presumably set by galaga)? Galago maintains presence in memory in the daemon, so they'd both be about the same speed as they both involve an IPC call. I guess that galago would be a good candidate for propagating not only away/idle/present, but also the busy state to applications. Setting to busy state would stop applications to show notifications (except critical ones), would stop playing sounds when friend logs in to IM, would not show pop-ups etc. This status would be useful for both enterprise use (don't pop up new chats while presenting) and home use (don't play GAIM notification sounds while watching DVD in fullscreen with sound directed to large speakers). Even status like sound-is-busy, video-is-busy would be useful in some environments (studios). -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
Yair Hershkovitz píše v Út 16. 01. 2007 v 11:39 +0200: Hi, I've been working lately on some bugs with RTL (right to left languages) support in Gnome. I have few suggestions to help improve RTL support in Gnome: 1) I want to start a mailing list for RTL support discussions ( [EMAIL PROTECTED] ???) 2) I think we should add an rtl keyword to bugzilla, for tracking RTL issues. There are also bugs, which are not directly related to RTL, but affect languages using combining characters, double width fixed characters or so. These bugs are ignored in Bugzilla, too. http://bugzilla.gnome.org/show_bug.cgi?id=302171 ... -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
Diego Escalante píše v Út 05. 12. 2006 v 16:23 -0500: Hi, xchat-gnome allows you to check more than one language in its Spell-checking preferences, I use it like that everyday and I have no problem. At least with spanish + english selected. The configuration dialog should allow to do the same thing. Yes, I think that configuration of more languages is nearly mandatory. It really irritates me that Gaim marks red my English communication if I am using Czech locale. Implementation in the Evolution gnome-spell new design with list_of_languages-list_of_words in the context menu is really cool. But setting the default using getlocale() is a good idea. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pam-keyring-tool as default?
Baptiste Mille-Mathias wrote: Hi David This is a distribution problem not GNOME, because pam_keyring is not part of GNOME Desktop, and the distributor does the integration of pam_keyring, so the best thing is to address your concern to the ubuntu developpers. pam_keyring does not integrate properly to multi-desktop environment - users of KDE or minimalistic desktops probably don't want running gnome-keyring-daemon. It only wastes memory there - they will not use GNOME applications. Current implementation is missing following feature: - Remember password. - If user selects other desktop than GNOME, quit. Thinking more about it, I can imagine trivial login helper (without glib dependency), which only remembers password and waits for gnome-keyring-daemon instance to pass the password to it. If it does not appear in defined time, it will quit. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: proposed architecture evolutions for GConf
Josselin Mouette wrote: being repeatedly faced with trouble about the GConf architecture, I've thought a bit about the global GConf situation, and I'm therefore proposing some improvements I'd like this to be discussed a bit before any code comes up. I'll try to summarize the current situation for those who don't know it and show my conclusions. I hope I won't be too much stating the obvious. It's not problem of Debian, but it should be addressed by future development, too: --makefile-uninstall-rule is incompatible with packaging systems http://bugzilla.gnome.org/show_bug.cgi?id=306924 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: categories in control center applets
Rodrigo Moya píše v Út 14. 11. 2006 v 16:24 +0100: On Tue, 2006-11-14 at 15:09 +, Richard Hughes wrote: On Tue, 2006-11-14 at 16:06 +0100, Rodrigo Moya wrote: Personal: Accessibility, Assistive Technology, Keyring manager, shortcuts, Network proxies, Power management, Preferred apps, Remote desktop, Sessions, Sound Is this ok? System: GStreamer properties Surely Network proxies and Power management should be System rather than Personal? ugh, right, for some reason I mixed Personal and System, so the correct layout is: Here is a complete set from OpenSuSE 10.2: accessibility-keyboard.desktop: Personal alacarte.desktop: LookAndFeel at-properties.desktop: Personal background.desktop: LookAndFeel default-applications.desktop: System display-properties.desktop: Hardware font-properties.desktop: LookAndFeel gnome-cups-manager.desktop: Hardware gnome-keyring-manager.desktop: Personal gnome-network-preferences.desktop: System gnome-passwd.desktop: Personal gnome-power-preferences.desktop: System gnome-screensaver-preferences.desktop: LookAndFeel gnome-screensaver-properties.desktop: System gnome-settings-mouse.desktop: Hardware gnome-settings-sound.desktop: System gnome-ui-properties.desktop: LookAndFeel gnome-volume-properties.desktop: Hardware gnome-xgl-settings.desktop: LookAndFeel gstreamer-properties.desktop: System gtk-theme-selector.desktop: LookAndFeel keybinding.desktop: Personal keyboard.desktop: Hardware orca.desktop: LookAndFeel pessulus.desktop: LookAndFeel session-properties.desktop: System vino-preferences.desktop: System window-properties.desktop: LookAndFeel beagle-settings.desktop: System tangerine-properties.desktop: System -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: opening a program with the middle button
Xavier Bestel wrote: Under AmigaOS you could do it that way IIRC: right-click to open the menu, then without releasing the right-mouse-button use the left-mouse-button to do your multiselections. Not that I advise using several mouse buttons at once. It was a nice feature allowing to do more actions in the menu during one rolling down. And a nice Amiga Multiselect utility also enabled multiple selections outside menu, in file lists, file managers etc. without using of Shift button: - Place mouse pointer over the first item you want to select - Press left button - Keep the left button pressed and press right button - Release left button, keeping right button pressed - Use left button clicking to add toggle items selection, keeping right button pressed - Release right button Both these features I often miss in GTK+. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LINGUAS file support in po directories
Kjartan Maraas píše v Pá 14. 04. 2006 v 15:51 +0200: tor, 13,.04.2006 kl. 14.49 -0400, skrev Rodney Dawes: Looks OK to me. Perhaps you could add a note about the no/nb thing too, so that we can ensure all the modules are using nb now as the locale name. That would help alleviate the concerns that Joe Shaw brought up yesterday in his blog entry about po/LINGUAS. I'll start removing the no.po files and references during 2.15.x. Hopefully we'll have them all removed before 2.16.0. That doesn't fix it for all the non-GNOME packages in a normal distro though. Maybe teaming up with the GNU translation project on that task would be best. It seems to be my fault I did many years ago in the CVSROOT/commitinto script. But now I don't have any access to it. I did a review of all po files in projects included into SuSE Linux and I fould many problems: - Non dialect translations in dialect-specific directories. - Translations provided but locale not present in glibc. - Translations with invalid locale codes. Some of these problems are related to GNOME CVS projects: https://bugzilla.novell.com/show_bug.cgi?id=162162 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Solution for OEMs/Gnome
Daniel Carrera wrítes: Hello, Thanks to all who gave suggestions. One of the suggestions turns out to work quite well: 1. Configure Gnome just the way I want it. 2. sudo cp ~/.g* /etc/skel Af least for .gconfd it is a bad idea. For .gconf you should prefer root's gconf database (but I still see a problem, that such customization is overwritten by a subsequent packages update, at least with the default gconf path). Also bad for .gnome2_private. In .gnome2 you should decide, whether keep session files or use gnome-session properties. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Solution for OEMs/Gnome
Daniel Carrera writes: Stanislav Brabec wrote: They are: /apps/panel/default_setup/applets and /apps/panel/applets. I see it. I also see /apps/panel/default_setup/objects. But I don't see a way to change what's there. Adding an icon means adding a new object and I can't see a way to do that from gconf-editor. Also, if I add an icon to my panel, it won't show up on Gconf. Gconf seems like an incredibly complicated way of adding an icon. And it doesn't seem to work at all. There is no connection between what I see on gconf-editor and the icons I see on my desktop. Yes, for panel it is true. But there is one chance, much simpler with GNOME 2.14 (it has merged gconf tree in ~/.gconf/%gconf-tree.xml): - Create new user account. - Configure it as you want. - Logout. - Open your ~/.gconf/%gconf-tree.xml in an text editor. - Find everything with /apps/panel/default_setup in its key. - Insert it to updated panel-default-setup.entries. You can take a help from user account with properly reconfigured panel. Except that I don't understand the contents of ~/.gconf These are XML files with user's changes of configuration read by gconf daemon. It seems easier to just cp ~/.gconf ~/.gnome2 /etc/skel/ Yes, but once user makes mistake, there is no way to reset to OEM default. Removing of ~/.gconf or using gconf-editor Reset to default, both will return to vendor state, not to OEM customization. - Edit .schemas or .entries in installed environment and use gconftool after setup. If you are talking about .../gconf/schemas/panel-default-setup.entries then I have no idea how to edit it. See above. - Use gconf-editor as root and set values. Doesn't give me the option to add an icon. Not icon, you are adding keys there. But even this is not intuitive, if you need a new drawer: - Go to lowest existing drawer - Right click in right empty window - Enter the key name, including missing part of the path and /. - Exit gconf-editor. - Run gconf-editor. Drawer and key are here. I have just filled it as a bug: http://bugzilla.gnome.org/show_bug.cgi?id=338239 - Change GConf path and use custom .schemas or .entries and use gconftool after setup. Still don't know how to edit .entries or .schemas. Like you said, they aren't exactly straight forward. In a text editor with a little understanding of XML. You can help yourself by looking at customized ~/.gconf directory. - Change GConf path and use separate GConf database No use unless I can generate a separate GConf database. Yes, you can, it should be simple: Create $sysconfdir/gconf/2/local-defaults.path (or edit $sysconfdir/gconf/2/path) Add there a directory (see the syntax in the path file). Create this directory and make it world readable (default in most distributions). I did never tried it, but I plan to test it for SuSE Linux 10.2 to simplify OEM customizations, which will survive upgrade. But as I wrote before, for panel all these ways are very unintuitive. You could say that :) It is unintuitive only for default panel setup. For other things, it is very straightforward. For example - change the init splash: - Find /apps/gnome-session/options/splash_image in gconf editor. - You see nice help, which will say you, what you can do. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notification icons hell (was Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager)
Vincent Untz writes: + HIG HIG HIG [Bug 99175] Need recommendations for notification area. HIG | General | Ver: unspecified http://bugzilla.gnome.org/show_bug.cgi?id=99175 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: policy request: 'make uninstall' should work
Joseph E. Sacco, Ph.D. writes: Thank you, Andrew. I will file the appropriate bug reports. As a maintainer of the GARNOME project, I find 'make uninstall' to be a necessary feature when exercising updates. Installing a later version of an application on top of an earlier installed version is just asking for trouble. As a package maintainer, I would like to see stronger requirement: All releases of packages with Automake based build system should be verified with Automake's target make distcheck. It verifies much more things. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release notes: first draft
Thomas Vander Stichele writes: However, not everyone in the GNOME community necessarily agrees with this. I got *a lot* of requests to add an mp3 recording profile to gnome-media. Historically, I've always refuted these requests because I agree that GNOME should not be endorsing them. I guess that adding this profile is OK. GStreamer command line parameters are not patented. Applications will make it active/displayed only if proper GStreamer module is installed. Profiles can be also bundled with gstreamer-plugins-*. Maybe the best solution. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Only one instance of a capplet should be allowed
Havoc Pennington writes: Virtually all apps really should be single-instance (though they often allow multiple document windows). There should be an API in GTK for it, And if such API will be created, it should be able to handle single instance with zero windows and zero documents opened. Such implementation can be used for quick launchers - initialized application will wait for open request and then very quickly initialize window. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations (was: Plan to fix icons [was: Re: breakage caused by removed icons from gnome-icon-theme])
Tommi Komulainen writes: On 2/7/06, Matthias Clasen [EMAIL PROTECTED] wrote: b) I believe we should pick a file format that did not already look antiquated when it was first employed in wanda the fish 5 years ago. Even gif animations look modern and featureful compared to this. FWIW we chose to use ANIs for animations in maemo basically because it supports 8-bit alpha *and* is already supported by gtk+. Making ANIs themable similar to icons is pretty straightforwad, just add ANI to the hardcoded list of formats icon theme currently supports. I guess that MNG (animated PNG) and JNG (animated JPEG) should be modern and widely accepted standards for animations. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: esd patch for control center
Rodrigo Moya wrote: Hi One of the things GNOME is doing on log in is to execute a couple times (one in gnome-session and one in gnome-settings-daemon) esound daemon. There is one related bug: unable to unset Enable software sound mixing (ESD) and set Sound for events http://bugzilla.gnome.org/show_bug.cgi?id=160335 But much better would be: Patch for moving libgnomeui to GStreamer http://bugzilla.gnome.org/show_bug.cgi?id=82340 Related: http://bugzilla.gnome.org/show_bug.cgi?id=94615 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
fam/gamin/inotify [was: Re: New schemas...]
Josselin Mouette píše v Pá 27. 01. 2006 v 08:59 +0100: Le jeudi 26 janvier 2006 à 17:42 -0600, Federico Mena Quintero a écrit : On Thu, 2006-01-26 at 14:51 +0100, Josselin Mouette wrote: Watching them with fam/gamin should be possible to achieve with the merged tree backend. Sadly, gnome-VFS is out of question because it depends on GConf itself. Rumor says that gamin isn't maintained anymore. But fam is in a sufficiently stable state now. But FAM does not support inotify, at least as is. Only dnotify and polling. And network notification. Let's just move to inotify directly. Other unixes will have to catch up. KDE does the same, too - for local files it uses inotify directly, for remote files it uses FAM. Does inotify handle NFS mounts? No, you need network notification, i. e. FAM running on both client and server. In theory, network notification daemon can use inotify on NFS server side. I am not a kernel hacker, but maybe it is possible to hide network notification into kernel and use inotify from user space. In SuSE/OpenSuSE we use a dirty trick: - gamin does not provide libfam.so.0 - gnome-vfs and libgda does not link with libfam.so.0 - gnome-vfs and libgda has a wrapper for dynamic loading of file notification: - Use libgamin-1.so.0, if gamin is installed and fam daemon is not running. - Use libfam.so.0 otherwise. - RPM dependencies should guarantee, that one of these two libraries is installed. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Manu Cornet wrote: Hi ! This happens with a lot of applications, is this a bug or a feature? If I understand correctly, that would be a feature Yes. This bug is a feature. For example if you want to open application and then use DnD, or if you want to open web link using DnD, you will end by searching a file of the same type on the disc to be able to open the application. http://bugzilla.gnome.org/show_bug.cgi?id=312399 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: strange linker error
Davyd Madeley wrote: Has anyone seen an error like this before: g77 -shared .libs/libHORIZON.la-2.o -Wl,--rpath -Wl,/home/davyd/install/lib -Wl,--rpath -Wl,/home/davyd/install//lib -Wl,--rpath -Wl,/home/davyd/install/lib -Wl,--rpath -Wl,/home/davyd/install//lib -L/home/davyd/install/lib -L/home/davyd/install//lib /home/davyd/install/lib/libFNV.so /home/davyd/install//lib/libFPSMATH.so -Wl,-soname -Wl,libHORIZON.so.0 -o .libs/libHORIZON.so.0.0.0 /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in .libs/libHORIZON.la-2.o /lib/libc.so.6: could not read symbols: Bad value collect2: ld returned 1 exit status I'm completely at a loss as to how to fix this. It seems PHP and Qmail have previously had problems like this, but I couldn't work out what they did to fix it. I don't know F77, but if it was C, I will try to #include errno.h and maybe search and delete custom definition of errno, which does not work. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Special folders in gnome
Murray Cumming wrote: On Fri, 2006-01-13 at 21:29 +1100, Jeff Waugh wrote: quote who=Mattias Eriksson I know that this have been discussed in the past, but no solution was reached then. I hope it will be different this time. I strongly agree that we need a solution for this (something GConf defined would be perfect for desktop/network administrators). Let's do it for 2.16? Why do we need to tranlate the on-disk folder name of Templates if we don't need to translate the folder names of home, bin, and all of the bash commands? Why isn't it good enough to translate it in the user interface? Nautilus already has a special folder heuristics - ~/Desktop is displayed with a different icon. Let's enhance this, make special icons for them and Add Real name in Properties. File selector needs something, too, to make things consistent. Maybe these folders should be mapped there to predefined bookmarks - Desktop is already there, and display only related bookmarks - for example in eog display Pictures but not Music etc. It should be discussed, whether to translate these bookmarks, or also folder names in file view and tree view, or make these directories hidden in folder view of Home and create something like places:// It can have some consequences - e. g. dropping translated Bilder to gnome-terminal must put /home/me/Pictures. Summary: Idea 1: - Special folder in bookmarks. Idea 2: - Special folders (including Home and Desktop) in places://) Put places:// to the default Desktop. Idea 3 (not mentioned above): - Make the list of special folders simply configurable. Additional idea 4 (not mentioned above): - Predefine also special folders for equivalents of the FHS directories in home directory. Define CONFIG_SITE to users, so they can seamlessly ./configure ; make ; make install to these directories. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Special folders in gnome
Frederic Crozat wrote: The shell is strange, and always will be, whatever we do. Problem is not really shell by itself (well, it can be for support / admin people) but shell scripts.. Well, we no longer translate Desktop anymore in the latest version of GTK File selector. What about a compromise - translate GTK+/Nautilus bookmarks, something like places:// but not folder names in /home/user. We do it for Desktop already, and it seems that nobody complains about it. To make it understandable, file selector and Nautilus should show special icon and a tooltip _(Special directory: Desktop), _(Special directory: Pictures). We can even add a configuration option to make special directories hidden in /home/user and visible only in places:// and bookmarks. This is nothing new, we had a hidden Desktop in GNOME 2.2 or so - ~/.gnome-desktop. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Special folders in gnome
Frederic Crozat wrote: Le vendredi 13 janvier 2006 à 15:00 +0100, Stanislav Brabec a écrit : What about a compromise - translate GTK+/Nautilus bookmarks, something like places:// but not folder names in /home/user. We do it for Desktop already, and it seems that nobody complains about it. Well, people might not complain to much for those inconsistencies because they don't care or think it is not worth complaining, but I still think it is. I was not accurate: - Not translate folder names in filesystem - Not translate folder named in file browser, either hide them or display them with a special emblem / tooltip - Translate them in File selector and Nautilus bookmarks - Translate them in optional places:// We can even add a configuration option to make special directories hidden... Configuration options are bad, specially in this case where we are not sure of the right solution so : let's user deal with it ;) We already have Hide files starting with dot and backups, why not add Hide special folders. It can be covered by proposal from: http://bugzilla.gnome.org/show_bug.cgi?id=311010 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Special folders in gnome
Frederic Crozat wrote: - Not translate folder names in filesystem - Translate them in File selector and Nautilus bookmarks I'm still seeing an inconsistency in the file browser. I think they should be translated there too and not displayed as english folder (same as Apple). We already have a (maybe/nearly) working implementation in current GNOME, which already displays translated names in both Nautilus and file selector: cat Pictures.directory EOF [Desktop Entry] Name=My Pictures Name[cs]=Mé obrázky Comment=My Pictures Comment[cs]=Mé obrázky Icon=gnome-devel Type=Directory Encoding=UTF-8 EOF I have tried ~/Pictures/.directory, but it seems not to be interpreted. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GConf --makefile-uninstall-rule is incompatible with packaging systems
Hallo. I want to discuss a design problem of GConf --makefile-uninstall-rule. I have been searching for the reason, why GConf database contains obsolete keys after correct package update. I found that it is a concept problem, which affects many packaging systems: GConf expects following update process: - --makefile-uninstall-rule for old schemas - perform files update - --makefile-install-rule for new schemas Packaging systems do (with a good reason): - preinstall of the new package - install new files - postinstall of the new package (--makefile-install-rule for new schemas) - preuninstall for the old package (too late for --makefile-uninstall-rule) - uninstall obsolete old files - postuninstall for old package - posttrans for new package (RPM 4.4 only) We need to do correctly following actions: - Package was renamed. - Package was splitted. - Package was removed. - Schemas file was moved to another package. - Schemas file was renamed. - Schemas file was removed. - Two schemas files were merged. - Two schemas files were splitted. - GConf key moved from one schemas file to another in the same package. - GConf key moved from one schemas file to another in different package. - GConf key was deleted, schemas file remains. There is no scriptlet for proper calling --makefile-uninstall-rule: - %pre scriptlet of the new package does not have the list of schemas included in the old version actually installed. - %post, %preun: It's too late, some schemas were replaced. - %postun: Even later. Not replaced rest was removed. - Any combined method I can imagine can fail, too. Thinking about it, it can be fixed by following ways: 1. Enhance packaging system: For example, RPM can implement preuntrans scriptlet started from the old package at the beginning of the update process. 2. Trace all old changes in schemas forever to be able to uninstall any old version. Very ugly. Nightmare for packagers. 3. Rebuild GConf database from scratch after uninstallation of any package. Relatively slow. 4. Enhance GConf: - Add serial to schemas file name. The serial has to be changed whenever key list in schemas file changes. - Add serial attribute to schemas file (or add serial to owner attribute). - Improve --makefile-uninstall-rule to uninstall only keys owned by proper owner (or add --makefile-uninstall-unowned-rule). - Optionally add ownership check to --makefile-install-rule - it should issue warning, when overwriting key with different owner. It can be OK if package is renamed, splitted, but generally it can mean problems. - Optionally implement --flush resp. --lock/--unlock option, which will signal all running gconf daemons to forget and re-read all cached values from selected source resp. lock the database and delay user daemons until database is unlocked. http://bugzilla.gnome.org/show_bug.cgi?id=306924 Note: This problem affects not only GConf, but also, for example install-info and other scriptlets. But because GConf database is more complex, problems caused by this incompatibility are real, not only theoretical. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote: 1) SCons intentionally ignores most standard *FLAGS (documentation says so). According to the devs, that is a feature of scons. This page has a workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings Although I think your real problem is badly written SConstruct-files. Thanks for the link. It is a feature for reproducible building of a binary. For distribution-release packaging it is a problem - distribution maintainer needs to change the whole distribution by changing of a few variables (e. g. RPM_OPT_FLAGS - CFLAGS). 2) It is hard to change hardwired default paths and change, say /usr/lib to /usr/lib64 for all packages. I think you are being unfair to scons. Ofcourse it is not right to hardwire architecture dependent paths in SConstruct-files, but that's not a problem with scons, it's a problem with bad SConstruct files. It is a problem of both, most paths are hardwired in SConstruct files, the rest in SCons. My problem was http://sourceforge.net/tracker/index.php?func=detailaid=1368255group_id=30337atid=398971 Likewise, someone could hardwire installation paths in Makefiles. Scons really is nothing more than a very nice make-replacement inside a very nice programming language. A fairer comparision would be bksys/scons (which kde is built with) against autotools/make. It means, that projects using scons without bksys are in the same situation as projects using make without autotools 10 years ago. Autotools were written just to prevent hardwired paths and features in makefiles. And bksys could change the quality of SConstruct files. From the view of the package maintainer, I would prefer move from make+autotools to bksys+scons and discourage move from autools+make to plain scons. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
My opinion: - Keep the rotate button. - Change menu item from Rotate... to View rotated... to prevent confusion. - Never implement auto-save without prompt. Eog is a viewer, not editor, and overwriting of original image would be a bad surprise. And optionally: - If user rotates image, Save rotation state to a special place and use it for next open (preferably shared with other applications). - Add menu item Reset rotation Details and rationale: Reinout van Schouwen wrote: Op Wed, 30 Nov 2005 22:59:06 +0100, schreef Manu Cornet: 1) Either not have any rotate button at all, and indeed use the EXIF data (but then what about older cameras, a lot of them don't have the appropriate sensor, do they ?) to diplay the right orientation. 2) Either keep its rotating functions, but then prompt the user (Do you want to save changes ?) when he closes the window and be able to actually save the picture. I agree to your points, but: why the prompt? Why not simply auto-save without prompting? In the case of an erroneous rotation, it is quickly undone and no data has been lost. At least with my camera (Minolta DiMAGE A1), this operation irreparably breaks EXIF MakerNote and destroys mid-size preview. It disallows to view such image back in the camera and loses special image information. For images, with size not dividable by 16, lossless rotation is impossible. Additionally, I have all original images write protected, but have to rotate them to view, because EOG does not yet respect EXIF. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
Claudio Saavedra wrote: Another point to take into account is the ammount of info that would be needed to save the last used rotation using a per-file basis. Probably that works in evince because a normal user doesn't have 50.000 PDF/PS documents, but maybe 50.000 images; and that is too much info. But it's still ten thousand times less than about 1GB of 5 png previews in ~/.thumbnails: [EMAIL PROTECTED]:~ ls -alR .thumbnails | wc -l 51929 [EMAIL PROTECTED]:~ ls -alR .thumbnails | grep total total 2498 total 470 total 1282 total 1468340 total 49859 Especially for small jpegs, thumbnail in ~/.thumbnails is often ten times larger than the image itself! This calls for: - Not creating thumbnail, if it is already present in the image itself and can be extracted in miliseconds. - Not creating thumbnails for small images. - Use of jpeg for thumbnails of jpeg images. - Not saving rotation, if it is already OK in the EXIF tag. And there are my Nautilus exifrot scripts. It's an ugly script, but changes exactly one or two bytes of image: http://www.penguin.cz/~utx/ http://ftp.penguin.cz/pub/users/utx/exifrot/ It would be very easy to make similar nautilus extension. The script is limited to cameras, which write EXIF rotation tag, but does not write useful value there. Note: gexif does EXIF repackaging, which causes loss of unknown data. - And off topic note about thumbnails: And because thumbnailer ignore directory symlinks (and file hardlinks), amount of stored thumbnails os often much larger than required. This calls for: - Use volume unique id and inode for primary identification of file. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing gobby? (Inkboard Collaborative Editing)
Chris Ball wrote: Hi, I'm not the author of gobby[1], but I'd like to hear thoughts on whether gobby should be proposed for inclusion in Gnome 2.14. Gobby is a collaborative text editor using GtkSourceView/GTK 2.6, with external dependencies of libgmp, gtkmm and libxml++. There are two libraries that are maintained by the gobby authors used: libobby and libnet6. Collaborative editing is an application many people don't seem to have realised is possible with their computers; I think having it available such that two GNOME users can easily start a collaborative session together would be massively beneficial. I am just now updating inkscape and looking at it, it has a completely different implementation of Inkboard Collaborative Editing: Using Loudmouth library it uses Jabber IM protocol to provide this feature. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Making GNOME crash
Matthias Clasen wrote: On Sun, 2005-11-06 at 17:39 +0100, Vincent Untz wrote: I'm not convinced that making HEAD unusable for everybody by enforcing this in gnome-session is the way forward. For one thing, it will drastically reduce the amount of testing that HEAD gets. I think making this the focus of a Gnome love day can have the same results without affecting the testability of HEAD for everybody else. And what about learning bug-buddy to submit these but reports without application crash - send backtrace and continue? -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cdda://, ftp://, news:// URIs and the default handler
Federico Mena Quintero wrote: We don't install a default handler for cdda URIs (in gconf's /desktop/gnome/url-handlers/cdda/*). That's not fine, and it's the cause of this bug. I got few bugs for SuSE Linux - clicking to news:// in firefox, ftp:// in evolution. All these bugs were simply fixed by adding proper desktop/gnome/url-handlers keys. IMHO we should enhance list of URIs known by core GNOME (and change control-center to allow to set them). I can open a bugzilla item about it. I have created a script, which updates all translations, too. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center-2.10.2 empty after upgrade/recompile
Marian Eichholz wrote: That's possible, because for some unknown reason, gnome 2.10.2 expected icons in /usr/share not in /opt/gnome2/share as before. So I had to frobnify the icon path to get my Evolution 2 running. Old GNOME has been using its own icon standard and has been searching icons in its own prefix or using GNOME2_PATH or GTK_PATH. Since version 2.8/2.10, GNOME and GTK+ follows XDG standards and uses variables $XDG_DATA_DIRS (for icons and MIME) and $XDG_CONFIG_DIRS (for menu layout). Both variables include only /usr. You can try: export XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/opt/gnome2/share/ export XDG_CONFIG_DIRS=/usr/local/etc/xdg:/etc/xdg/:/etc/opt/gnome2/xdg/ -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center-2.10.2 empty after upgrade/recompile
Nickolay V. Shmyrev píše v St 10. 08. 2005 v 19:51 +0400: Hi Marian. From the first look it's not clear what is going there. But the lines like 19986 stat64(/usr/share/icons/hicolor/icon-theme.cache, 0xbf887c40) = -1 ENOENT (No such file or directory) are very confusing. Probably you've forgot to update you icon cache or it's missing. Please search for it and reasons it's missing. It should be created by gtk-update-icon-cache program, probably it was forgotten somehow. But why it stats /usr/share/pixmaps/icon-theme.cache, too? I have tried to create one by gtk-update-icon-cache, but it broke the GNOME icons. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: audioconvert! the new super script to convert audio files! would you like to include it?
Behdad Esfahbod píše v Pá 05. 08. 2005 v 02:34 -0400: On Fri, 5 Aug 2005, James M. Cape wrote: Actually, on further thought, having the conversion also accessible by simply renaming the files would be really slick. Imagine this excha.nge: W00T. That would be uber cool. BTW, there's a page on live.gnome.org about powertools, stuff that are interesting for power users, but not _normal_ users ;). Unfortunately I cannot find the page right now. Google doesn't find it and FindPage on l.g.o is broken (no wonder). behdad 'where was that page Luis' esfahbod Hmm. Your idea calls for generalization. We have a MIME-type definition in each desktop filem, but it definition knows nothing about the fact, what can application do with listed MIME-type. Extended description could look: Have a (possibly unlimited) set of actions defined somewhere: Read (default), Edit, Send_via_Bluetooth... MimeType=class/type;class/anothertype; MimeType/Edit=class/type MimeTypeConvert(class/anothertype)=class/type MimeTypeConvertCommand(*/*,class/anothertype)=myconvert %s -t %M %S MimeTypeConvertCommand=myconvert -f %m %s -t %M %S Nautilus could take an advance of such database while renaming files or with menu item Convert to without much effort from application author. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-about-me
Diego Gonzalez píše v Pá 05. 08. 2005 v 01:43 +0200: On Mon, 2005-08-01 at 22:43 -0400, Adam Skobel wrote: I was looking through the new features of gnome 2.12 and looking at gnome-about-me and looking to see how it could be used to make the gnome desktop better, and realized that its asking for some information it already knows and isn't asking other basic information... Basically, the two things its asking me that I don't see a reason for is my email addresses, which Evolution already knows, my instant messenger IDs, which Gaim knows (also it strikes me as a bit odd that gnome-about-me labels the AIM field as AIM/iChat, I've never seen it labeled with iChat before, since iChat is just a program which happens to also support Jabber, so that label is confusing and makes no sense). Gaim doesn't use GConf or Evolution-Data-Server at all, this means that there is no easy way to use the information that Gaim knows, if they ever start to use GConf/EDS I will fix this issue. Gaim uses EDS via gevolution plugin (which is part of main package). But it can be even better. And project Galago integrates presence messages between GNOME, Gaim and EDS. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Detecting GNOME
Tomasz Melcer wrote: My friends says that he was running gnome, and he has: $ echo $GNOME_DESKTOP_SESSION_ID Default It means that he is running GNOME session called Default. For detection of latest KDE you can use variable KDE_FULL_SESSION. These variables are set by host computer, not by display computer, so it works for session started remotely, too. $ echo $DESKTOP_SESSION $ echo $WINDOWMANAGER These two are distribution specific. So that's probably not an answer. Also if you will run a program without these environment variables, but with DESKTOP one set, for example from another computer through network? Most people want to integrate only actually running desktop. Integrating alien command (started from different machine) is much more complicated - it can have different environment, theme, different home directory... -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
