Re: Module semi-proposal: gnome-shell
[orignally and accidentally just sent to Owen Taylor in private] Dear Owen, 2009/11/2 Owen Taylor otay...@redhat.com: GJS and SpiderMonkey: Currently gnome-shell is build using the GJS bindings to Javascript which work with the Mozilla SpiderMonkey Javascript engine. The comparison to seed/JavascriptCore has been discussed quite a bit in the past, I don't want to go into in detail here; basically the advantages for us are: I have not been following the GNOME shell discussions, but I wonder why we JavaScript is needed at all. Now that some of the core modules exhibit Python, suddently JavaScript is discussed. I have always considered programming and script languages as interchangeable (besides syntactic and refactoring sugar), so we need a good argument for adding new ones that just make the dependency stack larger and larger. I'd really strongly opt for C + Mono + one scripting language or C + Mono or C + one scripting language when we talk about the core desktop. I see no advantage whatsoever in a Babylonian approach -- unless you convince me with good arguments. In one sense SpiderMonkey is not a problematic dependency; SpiderMonkey is distributed as part of xulrunner, and will be present on virtually any computer where GNOME is available. Now that both the Epiphany web browser and Yelp [1] moved away from Gecko to WebKit, it seems to be very odd that we suddently introduce a XULrunner dependency again. Is this a political decision due to the collaboration of the GNOME foundation and the Mozilla foundation that was once announced? Ay best regards, Christian Neumair [1] http://git.gnome.org/cgit/yelp/commit/?h=yelp-3-0id=3da814fdf5c3dd8d209574fdeb99cc2cf6cbdfb4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module semi-proposal: gnome-shell
[orignally and accidentally just sent to Owen Taylor in private] Dear Owen, 2009/11/2 Owen Taylor otay...@redhat.com: This should be read as a semi-proposal: at this point I don't think gnome-shell is going to be ready to be shipped as a final component on the 2.30 schedule. But getting it into people's hands is important for having it be ready for GNOME 3. Reading some of the responses, major concerns wrt accessibility, theming and some other topics regarding quality control have been raised. I'd like to add another one: All the current desktop components (including the panel) have undergone usability studies from major companies (Sun etc.) and many individuals. Maybe you could point out similar usability studies for the shell? A proper investigation of usability is a prerequisite for not making GNOME 3.0 worse than GNOME 2.30. Most developers just seem to say try it out when they are faced with concerns about replacing a well thought-out system with one that doesn't seem to be, but didn't we drop this naive kind of development since the arrival of GNOME 2.0? I have serious concerns when we introduce a new desktop component with rave and fanboyism, but without any good arguments. We have enough polished UIs that do not improve productivity -- just try out KDE 4! We don't want no other KDE 4! Another concern: What happens if GNOME shell does not match the desired quality by the time of GNOME 3.0, i.e. what is the plan B? Do we delay it? Do we ship unfinished software that ruins our image of shipping good software? Finally: I am not trying to be rude. I am rather trying to explicitly state some concerns that seem to be under the hood of your very own email. I am not against changes. I also had some unpublished sketches and concepts regarding the desktop I want [which IMO should work like a personal life planner, i..e datebook + ..., where ... includes files, notes, photos, associations with other datebook entries]. It pretty much seems to be what you mention with the Zeitgeist (data colletion) engine to collect a rich view of how the user used their computer over time. I don't see this kind of data-centric desktop in the GNOME shell, so I don't see any new concepts but just lots of application-centric UI polish. I just want to see good arguments for a move to GNOME shell. best regards, Christian Neumair ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
How to suggest a patch for all distributors for all releases?
Nautilus used to become a memory hog for large zoom levels when folders containing videos were displayed [1]. This issue has recently been fixed by Alex Larsson [2] before the Nautilus 2.28 release. However, this fix is important enough to be applied by all distributors to all the supported Nautilus releases that are still out there, including LTS distributions. Is there any standard procedure for notifying distributors of such critical patches? Thanks in advance! best regards, Christian Neumair [1] https://bugzilla.gnome.org/show_bug.cgi?id=526091 [2] http://git.gnome.org/cgit/nautilus/commit/?id=a8097e57788ad735227489e6c51d06bedc796889 -- Christian Neumair cneum...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
g_format_size_for_display() unit bug report: historical unit discussion, conclusions
For whom it may concern: I filed a bug report [1] where I discuss the storage size conventions from a historical perspective, ultimately concluding that our current g_format_size_for_display() convention of using base-1024 units with a base-1000 (IEC) suffix “KB” is against all standards and conventions ever published (IEC, SI, historical conventions). Instead, it “just” replicates the Windows (XP) implementation. Thus, I proposed to make the usage of units correct, and leaned towards usage of base 1000 units where 1 KB = 1000 bytes. Please try to fully understand all conventions and their implications before commenting on the bug report. best regards, Christian Neumair [1] http://bugzilla.gnome.org/show_bug.cgi?id=554172 -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.24 Showstopper Review
Am Sonntag, den 31.08.2008, 23:51 +0200 schrieb Andre Klapper: GNOME 2.24.0 release is on September 22 (see [1]), and we still have enough 2.24 blocker bugs (and other bugs of course) to fix for everybody! Take a look, test help out, clean up our platform, make 2.24 better! ... I think I just found a new showstopper bug: http://bugzilla.gnome.org/show_bug.cgi?id=550647 When mounting volumes with GIO, if the mount helper does not return its console output at once (for instance for an internal floppy disk), the mounting application freezes until the entire buffer is read. This is particularly problematic as Nautilus tries to automount all volumes on startup. If you don't run a volume monitor, it is assumed that an internal floppy disk is present and you end up with a ~30 second application freeze at each startup. best regards, Christian Neumair -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Quotation marks: Using “” instead of
Alex Jones proposed [1] to change the quotation marks in Nautilus strings from the ASCII representation ... to the unicode variant “...”. I think the proposed quotation marks are aesthetically more pleasing, but I don't want to change this unless there is a GNOME-wide policy. I hereby propose to establish a GNOME policy of using “...” for quotations. Comments, objections? best regards, Christian Neumair [1] http://bugzilla.gnome.org/show_bug.cgi?id=532777 -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Reintroducing critical warnings?
I hereby propose to reintroduce the critical warnings we used to have during unstable release cycles. GNOME is becoming more and more mature, so it may be a good idea to shake out the remainder of the should not happen issues. best regards, Christian Neumair -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
SVN migration, any news?
As we all know SVN migration was cancelled due to problems with the migration script [1]. Maybe somebody from the SVN migration staff could come up with a short summary of what has happened since the failed migration and whether there are any plans to pick it up anytime soon. Thanks in advance! [1] http://live.gnome.org/Subversion -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Fwd: Re: Gnome Screensaver issues?
Weitergeleitete Nachricht Von: Wouter Stomp [EMAIL PROTECTED] An: [EMAIL PROTECTED] Betreff: Re: Gnome Screensaver issues? Datum: Tue, 21 Feb 2006 23:03:39 +0100 On 2/21/06, Diamond Software [EMAIL PROTECTED] wrote: I've been following the issues regarding Gnome Screensaver on the Ubuntu community forums, and just wanted to raise it here prior to the UI freeze (as suggested). In a nutshell, many screensavers require options to be configured and the Gnome Screensaver has no way of setting these. Performance and responsiveness have also been noted as problems. http://www.ubuntuforums.org/showthread.php?t=120071 With the feature freeze coming very soon now, could deviating from upstream and adding a configure button be seriously considered? In the mentioned forum thread there is practically an unanonymous consensus that the screensavers should be configurable. I'm forwarding this to GNOME desktop development list. I think the xscreensaver integration was rather a hack to show off and meant to be a transition solution until more GNOME screensavers are available, but I don't think there was much screensaver writing activity. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME cleanup series: Chapter 2
Am Freitag, den 06.01.2006, 13:44 -0200 schrieb Guilherme de S. Pastore: However, when we came to look at it, it was not only gnome-terminal that installed it: in my personal /usr/share/applications-registry, I have files installed by bug-buddy, epiphany, file-roller, gedit, gimp and gnome-vfs. Since then, Kjartan has been asking me hourly (ok, not that much) whether I have already sent this message to desktop-devel-list asking people what they think and, if they agree, to seek a complete purge of those for 2.14. Ditch 'em! :) -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GDFL - why is it bad? Debian could do better! (was: Re: Debian and the GFDL problem)
Am Donnerstag, den 05.01.2006, 11:11 +0100 schrieb Jordi Mallach: In most cases, policies were established before the voices against the license got strong, but I suspect that the strongest reason is that if the FSF recommends this one for docs, it must be The Right Thing. Well, we don't think it is ;) What are the precise problem with GDFL-licensed documents, when there are no invariant sections? We can have a policy to accept any GDFL-licensed document if it doesn't contain any invariant section. Debian could have done so as well, but they decided to distinguish themselves as unpragmatic nerds. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GDP mailing list - where are the archives?
The Feedback section of the style guide [1] mentions [EMAIL PROTECTED] as contact address. I think a simple email address makes it very hard to track the progress of an external request. Maybe somebody could arrange that the archives of the (supposed) docs mailing list are published on mail.gnome.org? I'm asking because I'd like to get a change into the styleguide and want to make the discussion transparent to the bug request which triggered the style guide discussion [2]. [1] http://developer.gnome.org/documents/style-guide/ [2] http://bugzilla.gnome.org/show_bug.cgi?id=324966 -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Get the applications notified when session is closing
On Sa, 2005-11-19 at 23:46 -0500, Havoc Pennington wrote: On Sun, 2005-11-20 at 11:56 +0800, Davyd Madeley wrote: I don't know why it isn't used. Perhaps someone else can shine some light on the reason. Apps are just sucking. Should file a bug vs. the apps that don't ask you to save... though it's admittedly overcomplex for apps to do it correctly at the moment. Maybe if we can find even one app that does it people can copy that one :-P I wonder whether anybody is working on getting session management into GTK+, or at least out of libgnomeui. The latter currently depends on CORBA, which is unbearable. Decoupling libbonoboui and libgnomeui doesn't seems to be possible since libgnomeui explicitly uses bonobo data types and semantics for GnomeApp, though. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pango performance work for Gnome 2.14
On Fr, 2005-11-18 at 09:13 -0500, Matthias Clasen wrote: one of the last GTK+ team meetings, we discussed that it would be nice to get all the Pango performance work done by Federico, Billy, Behdad and others into Gnome 2.14. To make this possible, we will shorten the release cycles of Pango (and GLib, since Pango depends on new GLib API), concentrating mostly on finishing the performance work. I know that we are a bit late (with 2.13.2 already behind us), but I have done a GLib 2.9.0 release today [1], and Behdad will follow with a Pango 1.11.0 release as soon as possible. Couldn't these changes be backported to the stable branch instead of squeezing two minor releases into the timeline meant for one minor release? [1] http://mail.gnome.org/archives/gnome-announce-list/2005-November/msg00034.html -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Argh! (was: Re: Getting rid of libbonoboui, action plan)
On So, 2005-11-13 at 12:44 +0100, Christian Neumair wrote: GnomeApp also seems to have a hard dependancy on BonoboDockLayout. It explicitly uses bonobo types in its API, so there is no way of getting rid of it, without getting rid of libgnomeui API, that is :(. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Argh! (was: Re: Getting rid of libbonoboui, action plan)
On So, 2005-11-13 at 12:06 +0100, Christian Neumair wrote: I'd like to propose a plan of getting rid of libbonoboui, by not forcing applications that depend on libgnomeui to depend on libgnomeui. libbonobui depends on libbonobo and therefore on CORBA, which is no good if you just want a GnomeApp. This should significantly reduce startup time. In future, many applications will probably use dbus for their shell instead of our ORB and its OAF infrastructure, so it's plain stupid to depend on it. Plan of action == 1. Analyze in what way libbonoboui and libgnomeui are interveawed (DONE) GnomeApp from libgnomeui uses libbonoboui's dock container and its dock items, for managing its menu, its statusbar and its toolbar. Also, gnome_gtk_module_info_get calls bonobo_ui_gtk_module_info_get. 2. Chop libbonoboui deps from libgnomeui (TODO) From taking a quick peek at the code, it looks like all of its functionality could be replicated with the GtkUIManager. We also have to decide on whether we want a global /desktop/gnome/interface/toolbar_detachable, and /desktop/gnome/interface/menubar_detachable setting. If so, we probably want a GtkSetting, and add separator menu items, and add new API to GtkToolbar and GtkMenu/GtkMenuBar. I think this is not very important, though, although it slightly changes the UI of the applications. The restore_window code from gnome-mdi-session.c is currently commented out, so it won't be any regression to not reload the UI correctly. Sidenote: I wonder whether we need a new session management framework which more suitable for saving/reloading UI state. Epiphany for instance uses its own format (~/.gnome2/epiphany/states.xml). I think the GTK+ plans [1] used to contain some session management stuff, not sure where it has gone. The gnome_gtk_module_info_get call is a bit tricky. I think we can copy the libgnome deps from libbonobo_ui_module_info_get to libgnomeui, removing any libbonoboui/libgnomeui dependancy, and making libgnomeui depend on the LIBGNOME_MODULE, and making LIBBONOBOUI depend on LIBBONOBO_MODULE and LIBGNOME_MODULE. The i18n stuff from do_low_level_init can also be moved (copied?) to libgnomeui. Calling both in sequence shouldn't do any harm, and some apps IMHO still rely on bonobo-i18n. 3. (Topaz) Remove libbonobo and libbonoboui. Comments, opinions? [1] http://www.gtk.org/plan/2.10/ GnomeApp also seems to have a hard dependancy on BonoboDockLayout. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Eel and Nautilus branched
Am Montag, den 03.10.2005, 09:28 -0400 schrieb Luis Villa: On 10/3/05, Alexander Larsson [EMAIL PROTECTED] wrote: Eel and Nautilus has been branched for 2.13. 2.12.x work go in the gnome-2-12 branch. Any interesting plans for 2.13/14? [1] and more fixes. I'm also quiet optimistic that we can finally get completely rid of bonobo/CORBA and integrate with a new metadata framework [2]. [1] http://live.gnome.org/Nautilus#UpcomingReleases [2] http://freedesktop.org/wiki/Standards/shared-filemetadata-spec -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Strange window list behaviour
Am Donnerstag, den 29.09.2005, 13:10 +0300 schrieb Yaron Tausky: Hi there, Well, I guess this question's been bugging me since the beginning of time (or the first time I used GNOME ;-), so here goes: is there any particular reason for changing the size of the window list (the panel applet) buttons whenever the list changes? This is the #1 usability nightmare for me. I totally agree with you. I've changed the list size to a constant value by setting its minimum/maximum size to the same value. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [BUG] Volumes not translated due wrong POTFILES.in
Am Donnerstag, den 22.09.2005, 10:57 +0200 schrieb Luca Ferretti: Il giorno mar, 20/09/2005 alle 13.32 +0200, Luca Ferretti ha scritto: Here is a ugly typo in POTFILES.in Filed as bug# 316914 http://bugzilla.gnome.org/show_bug.cgi?id=316914 It's quiet obvious that we want to have those translated. Feel free to patch POTFILES.in, and please don't forget to send an e-mail to gnome-i18n. We still have 2 weeks for translation, and the worst that can happen is that translators don't manage to update their translation, which would have the same effect as not having picked these strings up in the first place. Thus, there is no danger of regressions. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior
I've noted significant inconsistencies wrt the handling of invalid arguments to functions. While GTK+ seems to take care of notifying the API client about failures by having various g_return_if_fail statements in front of virtually every public API, the EvolutionDataServer according to Sven Herzberg has asserts in the very beginning of many public API codeblocks. GnomeVFS instead often seems to not check for this at all, resulting in NULL strcmps etc.. Just check out gnome-vfs-mime-handlers.c and you get the gist. I'd really like to have a GNOME-wide policy for dealing with public API and invalid arguments. If we feel like the traditional C route is good, we can remove all of these codeblocks for the sake of performance. I think some of the asserts/return_if_fail statements were left out for exactly that reason. I suppose this has a measurable performance impact for little helpers that are often called. On the other hand, programmers using our API will probably kill us if we remove them. So maybe we've got to make a decision whether we should enforce the usage of g_assert or g_return_if_fail. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya: there is no reason to force us to do GNOME 3.0, but since many GNOME libraries will be disappearing with Ridley, we might want to call it 3.0, so that we don't have to maintain the old libraries around. Also, as we deprecate most stuff in libgnome/libgnomeui, we might want to think about the role of those libraries. I would suggest we use them for having high-level desktop oriented things in one place, like, for instance, talking to the panel/window manager/file manager/etc, notifications, services (libgnomeservice), libegg, icon theme. Thus, as we reduce the number of generic libraries by getting them into GTK+, we also reduce the number of specific, high-level libraries, by putting them into libgnome/libgnomeui. Since we'll always need these high-level libraries, instead of killing libgnome* (http://live.gnome.org/LibgnomeMustDie), it might be much better to change its purpose. All those would be enough to justify a GNOME 3.0 :) Does this also mean that we can get rid of deprecated API like GtkTree, GtkCList or GtkFileSelector? -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomedb to Ridley , why not ?
Am Montag, den 22.08.2005, 20:03 +0200 schrieb Roberto Majadas: If anyone don't know libgda , it's an API for database access (...) I think that could be interesting to have something like qtsql ( http://doc.trolltech.com/4.0/qtsql.html ) integrated in the future ridley project like in QT. (...) comments ? Isn't that *exactly* that kind of specialized functionality we want to keep out from glib/GTK+. Will a significant percentage of applications really profit from uniform SQL DB access? Are there any candidates who currently don't use it? -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: creating iso
Am Samstag, den 20.08.2005, 22:21 + schrieb adel: hey, what about right click on CD/DVD device then make iso? The Nautilus CD Burner 2.11 adds a Copy CD/DVD entry for CD-ROM drives. You can use that functionality to create a disc image as well. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dumping gnome-smproxy in 2.14
Am Samstag, den 23.07.2005, 00:58 +0200 schrieb Christian Neumair: Am Freitag, den 22.07.2005, 08:38 -0600 schrieb Elijah Newren: On 7/22/05, Mark McLoughlin [EMAIL PROTECTED] wrote: On Fri, 2005-07-22 at 09:57 -0400, Luis Villa wrote: Honestly, any reason to wait to 2.14? I'd like to, but I just don't think its very good form to do it post feature freeze. When it fixes all kinds of bugs that ought to be considered showstoppers? Also, from your explanation it didn't sound like you were proposing to add any features, merely to remove a Feature (i.e. BUG). Having read lots of bug reports about the first three example bugs you list (I guess the other two were before my time? Don't know why I didn't know about them), two of which basically make Gnome unusable, and additionally having been affected by all of those three on various occasions, even if this did break feature freeze I think you'd likely get the necessary approvals. Also, Havoc's comments about removing it seem instructive here (he thought it had already happened and that it should if it hadn't--and that was two years ago): http://bugzilla.gnome.org/show_bug.cgi?id=118063#c27 Did anybody of you already ask for approval? Mark, are you willing to handle this? Obviously not. I will ask the release team and inform you about the feedback. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
finally dumped (was: Re: Dumping gnome-smproxy in 2.14)
Am Montag, den 25.07.2005, 08:34 -0600 schrieb Elijah Newren: On 7/25/05, Christian Neumair [EMAIL PROTECTED] wrote: Am Samstag, den 23.07.2005, 00:58 +0200 schrieb Christian Neumair: Did anybody of you already ask for approval? Mark, are you willing to handle this? Obviously not. I will ask the release team and inform you about the feedback. He's the maintainer and I don't see how it breaks any freezes. Mark knows he needs to get approval and when not to--he was just bringing it up on d-d-l because it had the potential to affect lots of stuff across the board including things not Gnome. He felt it was kind of late to make such a change despite the fact that it didn't break freezes--but further investigation seemed to show that we couldn't find any adverse side-effects and the benefits were tremendous. OK. Thanks for clarifying this. Just for the ones among us who don't track CVS: gnome-smproxy has been ditched as of today :)). -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dumping gnome-smproxy in 2.14
Am Freitag, den 22.07.2005, 08:38 -0600 schrieb Elijah Newren: On 7/22/05, Mark McLoughlin [EMAIL PROTECTED] wrote: On Fri, 2005-07-22 at 09:57 -0400, Luis Villa wrote: Honestly, any reason to wait to 2.14? I'd like to, but I just don't think its very good form to do it post feature freeze. When it fixes all kinds of bugs that ought to be considered showstoppers? Also, from your explanation it didn't sound like you were proposing to add any features, merely to remove a Feature (i.e. BUG). Having read lots of bug reports about the first three example bugs you list (I guess the other two were before my time? Don't know why I didn't know about them), two of which basically make Gnome unusable, and additionally having been affected by all of those three on various occasions, even if this did break feature freeze I think you'd likely get the necessary approvals. Also, Havoc's comments about removing it seem instructive here (he thought it had already happened and that it should if it hadn't--and that was two years ago): http://bugzilla.gnome.org/show_bug.cgi?id=118063#c27 Did anybody of you already ask for approval? Mark, are you willing to handle this? -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [PATCH] single-click list view hand cursor hovering
Am Mittwoch, den 13.07.2005, 12:11 +0200 schrieb Alexander Larsson: On Mon, 2005-07-11 at 20:24 +0200, Christian Neumair wrote: From bug 105521 [1]: Also, I'm not sure we should do this change at this late stage. As the comment in the bug says, other modules needs to change to be similar too, and ui freeze is soon (july 25). What says the maintainers of file-roller and gnome-search-tool? They've just committed patches or patches waiting to be committed when we've ready. -- Christian Neumair [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Porting gnome-control-center to GtkIconView
Currently, the gcc shell uses GnomeCanvas. That doesn't sound like a good idea, since we have the shiny new GtkIconView in GTK+, which feels way more native than the custom GnomeCanvas hackery. I've succeeded in doing the GtkIconView port [1], and would like to get some feedback. Does it feel nice to you? What could be improved? Known issues (help appreciated): - sizing I was unable to figure out how to sanely make GtkIconView request a minimal amount of space in a vbox which contains other icon views, without shrinking to death nor expanding. The space seems to be equally allocated to both treeviews although the parent vbox isn't homogenous. - label background I was unable to assign the same background to the labels which is used by the iconview background. [1] http://manny.cluecoder.org/cc-icon-view.diff -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: Default Session in GDM
Am Freitag, den 29.04.2005, 15:16 + schrieb Susant Kumar Padhi: I want make My session as the default session. /etc/gdm/gdm.conf, DefaultSession -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Simple menu editor
Am Montag, den 11.04.2005, 10:25 +0100 schrieb Mark McLoughlin: Hi, I'm just about to import a very simple menu editor to gnome-menus based on Calum's mockup some time ago: http://www.gnome.org/~calum/usability/specs/menu-edit/ Build gnome-menus HEAD and run gmenu-simple-editor to try it out. This is pretty much the same as Christian's gnome-menu-editor, but with less features. I thought it might good idea to try and explain why I went with a new editor with less features :-) Note that the menu editor I put up is not only based on Calum's proposal, we also were and are still in contact to improve it. Most of the features that it has are actually based on proposals Calum sent me. He recently seemed to be quiet satisfied with the features it provides. I don't really see any point in developing more menu editors, taken that we're on the 2.12 track. Instead, we should focus on ranting in private or public on gnome-menu-editor, making usability studies/improvements. People will be confused what the official way to edit their menus is. If you want, I can also completely remove my codebase from CVS and your implementation can be shifted to the gnome-menu-editor, if my code quality doesn't match your requirements and you don't want to dig into the gme-util.[ch] mess. I'm really convinced that we need one common effort. -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1
Am Dienstag, den 08.02.2005, 04:07 +1100 schrieb Jeff Waugh: quote who=Jody Goldberg 2.10 will include an updated variant of the old ximian OSX style flat layout. I noticed that was changing, but it looks a bit... Wacky in the current tarball release. ;-) It does look ideal with the default arrangement of .desktop files. Jeff, Chrisian raises some reasonable points with his tab based design. The OSX style layout flounders badly when the number of capplets grows larger than about 4 x 5. Enforcing that limit requires a white-list or you end up with windows style random capplet additions with every new application. A promising solution for the remainder is an 'Other' tab. OS X has an 'Other' category, designed to fit the screen height, which works reasonably well: -- Category [ ] [ ] [ ] [ ] [ ] -- Category [ ] [ ] -- Other [ ] [ ] [ ] -- A tab for each category hides icons unnecessarily, requiring another click to even find out what's there, let alone click it. :-) Hard to feel like you have an overview of things when they're stacked up in piles (which is what a notebook is). As Jody pointed out, the Apple layout doesn't work very well for many items - and we HAVE many items. While about 20 in the default setup are still OK, we have to deal with the fact that new items will be added. So the Apple approach seems to be badly scalable. Oh, just as a sidenote: We have very long names and descriptions for each pref item. The current GtkIconView doesn't allow us to use PangoLayouts, thus making it possible to chop or shorten text, which results in uneven icon spacings. But will - once it can deal with PangoLayout - crippled text (Menus ... lbars) really help users to identify a target they look for, or are icons meant to convey 90% of the meaning of a capplet? Note that this might become problematic for 3rd party capplets. After all, I think the ListView approach seriously beats the icon approach. Scanning a column (either text or pixbuf) just seems to be so natural and reminds me of quickly reading a newspaper (one or two words each row) if you're in a hurry, so that you can see at a glance whether an article is interesting. -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1
Am Montag, den 07.02.2005, 13:26 -0500 schrieb Havoc Pennington: On Mon, 2005-02-07 at 19:18 +0100, Ronald S. Bultje wrote: On Mon, 2005-02-07 at 17:42, Jeff Waugh wrote: quote who=Christian Neumair It is a little app which is meant to eventually replace the preferences menu. http://manny.cluecoder.org/packages/control-center-gui/screenshot-0.1.png So, I don't agree with your starting point (tabs hiding things, rather than OS X flat-panel categories style which may be better), but I strongly and enthusiastically encourage you to continue experimenting with new ideas for the control-center interface! Very rocking. I kind of agree with your objections, but I definately like this better than the OS X flatlook, which is rather, well, flat and simple and makes you overlook controls (imo). Flat and simple is good because you can launch any item in two clicks (launch shell, launch item). Of course, with the menu it's only one click... Well with my proposal it's pretty much the same (category-capplet). The main difference is the UI arrangement - I've chosen the list view, because I really don't think the icon view is aesthetically appealing in this context and doesn't allow you to find quickly what you're looking for, at least with the current capplet organization; icons in general only seem to work if you have terse item labels. Arranging them in two dimensions forces the user to look at each grid element which is out of the question. I still maintain that futzing with the shell is totally missing the real gains to be made, though, which are in actually organizing the overall prefs. I think we all agree on that. -- Christian Neumair [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1
Am Montag, den 07.02.2005, 13:36 -0500 schrieb Jody Goldberg: On Mon, Feb 07, 2005 at 01:22:06PM -0500, Havoc Pennington wrote: The control-center is for desktop settings, i.e. stuff that does not appear to users to be associated with any particular application. [...] We need to give developers a place to put these things. While I agree that the primary control-center page is not the place for it, a secondary tab seems like a nice central location. My rationale is the plethora of menu entries under windows that consist of app - - run app - configure app What's wrong with the current Run Application, Edit-Preferences pattern? I only edit application preferences when using apps. regs, Chris ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
