Re: new external dependency: libview
It would be very nice to port these widgets to C and get them wrapped properly in C++. As awesome as parts of libview are, a lot of people who might otherwise use it pass over it because of the C++ requirements. I don't know when any of us at VMware will have time to do it, but if it would mean merging these things into GTK+, we could probably find someone to do it over the next few months. -David On Wed, May 28, 2008 at 6:44 PM, Hubert Figuiere [EMAIL PROTECTED] wrote: On Thu, 2008-05-29 at 03:00 +0200, Étienne Bersac wrote: libview has some interesting widgets that may worth entering Gtk+ (like FieldEntry, Header, etc.). Other should be merged inside Gtk+ itself (DeadEntry, ContentBox, UndoableTextView, etc.) Except that FieldEntry, Headers, DeadEntry, ContentBox and UndoableTextView are implemented using Gtkmm, in C++. This would cause a circular dependency between Gtk+ and Gtkmm. Nonwithstanding that I doubt that C++ code would be acceptable in the Gtk+ codebase. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ 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
As the author of SexySpellEntry/xchat-gnome, here are my (biased) suggestions: 1. Use a subclass of GtkEntry -- not only does this make porting easier (since SexySpellEntry is implemented as such), but most of the entry boxes inside UIs don't need spell-checking. There are some improvements I'd like to make if porting SexySpellEntry directly, which I'm happy to talk about with interested parties. 2. Include a standard language picker widget. Lots of applications are going to want this, and it's going to become messy if people can't just drop in something. This has applications beyond spell-checking too. I personally feel that it's nicest to check words in the union of selected languages, so that users don't have to micro-manage settings for each UI element that they may potentially be typing in. 3. Merge the backend for the spell-entry and textview spellers. GtkSpell3 (currently only in cvs) shares a lot of similarity with SexySpellEntry, and it was always my intention to merge them together. There's an opportunity to do some nice spell-context API for extending spell checking facilities into custom widgets too. -David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
What in particular isn't possible with the 6-month cycle? -David On 9/7/06, Pat Suwalski [EMAIL PROTECTED] wrote: Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC GnomeGoal #3
gnome_config is deprecated, in favor of GKeyFile. Unfortunately, GKeyFile is a lower-level API than gnome_config, making you do things like figure out where to put the file yourself (and really, with key:value files, figuring out where to put it is the harder part). -David On 8/11/06, Shaun McCance [EMAIL PROTECTED] wrote: On Fri, 2006-08-11 at 11:22 +0100, Bastien Nocera wrote: Heya, I've written up on GNOME Goal #3: http://live.gnome.org/GnomeGoalsSaveState Currently, a lot of applications will be using GConf to save state, like window sizes, whether or not a window is maximised on startup, etc. This is against GConf policy, as GConf might be read-only, or locked down, but this sort of information should still be saved run-to-run. I'm awaiting comments on this, before making it official. Vincent mentioned that it would be a good idea to get code to save state in a library, although there isn't that much code to be shared IMO. We have a very easy library for doing this: libgnome. The gnome_config family of functions are easy to work with for something this simple. http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-config.html It's what Yelp uses to store the width and height of its window. See here: http://cvs.gnome.org/viewcvs/yelp/src/yelp-window.c?rev=1.210view=markup Search for window_configure_cb. Search again. And now a third time. Ah, there it is. And the code for getting that information is in the window_init function. It's way less code than using GKeyFile. And since we're on the subject, I consider it a fundamental flaw in all of these approaches that we're storing window positions and sizes without regard for what machine we're running on. (Yes, Yelp has this flaw too.) If I'm running multiple machines off the same NFS home directory, and one of them has a smaller resolution, bad things will happen. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bring a conlusion please
And regarding what Gnome is and to whom it caters discussion, after 14 releases I think it's too late to start such a topic. It's never too late to reevaluate where you are, what you want to do, and how to do it. The computing environment that GNOME 1.0 fit into is different than the one 2.0 did, different from the one 2.14 did, and it will be different in 2.30 (maybe we'll hit 3.0 by then ;). Every so often, someone will propose *something* that won't fit into the current vision for what is GNOME and if it's compelling enough, that vision may have to be redefined. We've seen this debate come from mono-based applications for a while (vis-a-vis desktop environment vs. platform), and we're starting to see it with the software surrounding mobile platforms such as the N770 and OLPC. To say that we're going to keep GNOME focused on the same vision of a desktop that fueled 2.0 will only serve to limit possibilities and frustrate the developers who are working so hard on cool things. Lastly, Gnome needs a new next-gen language. Please elect/find a product manager that most Gnome devs and the Board agree that is good for the job (could even be someone inside the Board too, or the Board itself), let him read the lists, research and let him decide if the next-gen language of Gnome is Python, C# or Java. Point of the matter is that fewer and fewer graduates learn C++ and even fewer learn C. For Gnome to appeal to new programmers, a new, fully supported by Gnome, environment must be found. This is being stated over and over again for 3 years now, but no one does anything about it because people can't agree. This is why a product manager (or a Board that takes technical decisions) is much needed to give an end to these disagreements after they have studied all opinions and pros and cons. One of the strengths of the GNOME platform is that you're not limited to any one language. Blessing a single language as the next-gen language of GNOME will cause nothing but flamewars and animosity between people who are really working towards the same thing. We have excellent environments for both python and CLI languages, and a lot of the other bindings (such as Java and ruby) are improving rapidly. Surely a platform with robust bindings into many languages is a better option than just catering to the university-taught-platform du jour. -David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libnotify and the HIG
Also consider what it would be like with 3 or 4 of those bubbles all over the screen; this is not an uncommon experience with some other notification systems, and it feels a bit like whack-a-mole. One of the things that struck me as nice about the n-d design was that most notifications popped up in a predictable location. Just because an application has a visible presence on the screen doesn't mean it has to be used as an anchor point; I remember seeing in a mock-up somewhere a disk full notification pointing at the computer icon on the desktop! Your song notification would be just as meaningful, if not more, in the lower right, with a now playing label and the muine bass clef icon. The amount of response elicited by that notification is pretty limited, since it's mostly informational. Add a next song action and you'll probably cover most of the interaction that would result from it. Icons, text and actions can all serve to associate a notification with the application or data it's about. For things like new song playing or power unplugged, the important thing isn't the icon on the screen, it's the music coming out of the speakers or the plug which just came loose on the back of the laptop. Anchored notifications have their place, but please consider whether it's really useful to do it. -David On 4/19/06, Wouter Bolsterlee [EMAIL PROTECTED] wrote: På Sun, Apr 16, 2006 at 11:58:17AM +0100, Mike Hearn skrev: I can't think of any compelling reason why you would need to associate a power management notification with some widget on screen, because it's not really to do with anything on screen specifically. It's just computer stuff. Being able to point notifications at widgets is a great feature that should not be underrated. Consider [1] and imagine the same bubble appearing at a random location on your screen without any clue what it belongs too. mvrgr, Wouter [1] http://uwstopia.nl/blog/2006/03/muine-notifications -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl i wondered what went wrong -- and you will know us by the trail of dead -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFERh4EP7QTTiUKY+sRAjnFAJoCZO43dKemKDXKVWIQjfzKAT2PywCaAubZ ymZXjn+r83sU3cTZh2VaoFY= =PFti -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
