Re: GNOME and non-linux platforms (release team please stand up)
On 22/07/2009, at 3:54 PM, Calum Benson wrote: On 22 Jul 2009, at 20:06, Jason D. Clinton wrote: Obviously the alleged pointlessness of something that we are arguing about is relevant. Whether or not there are--you know--actual people using said OS is what this is really about. And apparently even Sun doesn't think so since they no longer invest the same level of resources in it that they once did. FWIW, in relative terms the number of people working on the GNOME desktop at Sun compared to say, 5 years ago has probably increased, but I'm aware that this isn't necessarily the general community perception. Maybe we just need to rescue Gman from his current marketing role and give him back a proper job :) Harsh! :) (but thanks all for providing the amusement to waste away a couple of hours at SFO) Gman ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On flames (Was: GNOME and non-linux platforms)
On Fri, Jul 24, 2009 at 5:15 PM, Alberto Ruiz wrote: > > them are off-list seething hate mail from current and former Sun and Red > Hat > > Jason, it is not acceptable to point to RH and Sun people over here, > *off-list* ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On flames (Was: GNOME and non-linux platforms)
2009/7/24 Jason D. Clinton : > On another note, there are now just as many emails in my GMail view of this > conversation about the thread as there are of the thread itself (many of > them are off-list seething hate mail from current and former Sun and Red Hat > employees). By my count, there would be a 36% less noise in this thread if > people would stop appointing themselves d-d-l police. Incidentally, this is > the same reason that #gnome-hackers is now practically dead--everyone is so > afraid of offending un-written, ambiguous rules of content on #gnome-hackers > (apparently enforced at a whim vis-a-vis the ban of Rupert) that no one > talks at all. Jason, it is not acceptable to point to RH and Sun people over here, when it was you the one who brought the whole "Sun should realize that OpenSolaris is a dead end" statement to a list where none can do anything to make the relevant people at Sun realize such thing even if it was true. If you want to see desktop devel and #gnome-hackers going back to the good old times where they were useful communication channels, start by behaving yourself and consider the usefulness and how provocative your messages can be before clicking 'Send'. -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Fri, Jul 24, 2009 at 12:52 PM, William Jon McCann < william.jon.mcc...@gmail.com> wrote: > Hey Jason, > > On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clinton > wrote: > > On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson > wrote: > >> > >> So if it turns out that the GNOME community like the general direction > >> we've suggested for the control center, then sure, I'd certainly like to > see > >> us widen out the discussion to visual panels as well. > > > > Has there been any movement with regard to the mouse-over pop-up menu > > criticism that I pointed out--that it breaks the metaphor and there's no > > precedent for it? There wasn't any response on the blog post[1] from the > > parties involved with creating the mock-up. Another criticism--not > mine--was > > the 90 degree rotated text for category naming. I didn't see a response > to > > that either. Communication needs to be two-way. > > > > [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/ > > This is pretty far off topic. I think discussing a control center > design is really important. But it should probably happen here: > http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html I am not on gnome-cc and have no desire to be. I didn't bring this topic up and I think it's entirely relevant since Sun is essentially saying here that they are offering up some two-way cooperation--the topic of the thread. Those criticisms need to be addressed--even if it's just saying there's a good counterargument that will be coming at some later point--if they aren't going to replied to in the location in which critiques were solicited. On another note, there are now just as many emails in my GMail view of this conversation about the thread as there are of the thread itself (many of them are off-list seething hate mail from current and former Sun and Red Hat employees). By my count, there would be a 36% less noise in this thread if people would stop appointing themselves d-d-l police. Incidentally, this is the same reason that #gnome-hackers is now practically dead--everyone is so afraid of offending un-written, ambiguous rules of content on #gnome-hackers (apparently enforced at a whim vis-a-vis the ban of Rupert) that no one talks at all. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
> [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/ wow I can't believe I missed this, and didn't read the accompanying wiki page http://live.gnome.org/UsabilityProject/Whiteboard/ControlCenter I'm such a bad citizen at times :( Thanks for pointing to this work, seems Sun have put quite an effort behind testing, generating prototypes and alike. It's nice to see someone's doing this, hiding away in the wiki is bad though :( I think we could really benefit from a ux.gnome.org site for demonstrating new ideas and creating concrete mockups and cataloging testing data from various organisations who are performing usability testing or have in the past. We could even possibly get people grazing through and helping out, especially people like the gnome-look community which is thriving and still producing content on their brainstorm pages... http://gnome-look.org/index.php?xcontentmode=185 Handing all of this untamed talent, mentoring and directing them within a structured framework could help build a thriving user experience community. Imagine for a moment the litestep and afterstep desktops, people configured them to crazy extents making whole new user experiences within nothing but a few hours of dedicated concentration of how they want things to be. Now take a look at GNOME shell, we've basically got something 1,000,000 times more powerful than litestep for hackability, this is next to a community of willing and dedicated people... The thing that gets me is, they don't currently seem to be connected. Personally I think that ux.gnome.org is the way to go. If we can create a framework for distilling the good ideas down from multiple sources, then I believe our user experience will become second to none. Any thoughts, flames, rants? BR, K 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: GMime as an external dependency
On Fri, Jul 24, 2009 at 2:01 PM, Luca Ferretti wrote: Hi, > 2009/7/24 Andre Klapper : >> >> If so this totally blocks GTK3 readiness for applications that depend on >> gtk-sharp I assume? >> > > OT: could gobject-introspetion help us to keep C# bindinding updated > to latest version? If yes, isn't 3.0 the right time to "port" all > bindings it? It'd be really hard to do this without breaking API/ABI for the popular bindings. So I'd suggest not to do this for major bindings. However, for more minor bindings or for binding faster moving libraries, or for creating a binding for existing C code, yes, looking at using the introspection annotations and tooling makes sense. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
2009/7/24 Andre Klapper : > > If so this totally blocks GTK3 readiness for applications that depend on > gtk-sharp I assume? > OT: could gobject-introspetion help us to keep C# bindinding updated to latest version? If yes, isn't 3.0 the right time to "port" all bindings it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Hey Jason, On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clinton wrote: > On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson wrote: >> >> So if it turns out that the GNOME community like the general direction >> we've suggested for the control center, then sure, I'd certainly like to see >> us widen out the discussion to visual panels as well. > > Has there been any movement with regard to the mouse-over pop-up menu > criticism that I pointed out--that it breaks the metaphor and there's no > precedent for it? There wasn't any response on the blog post[1] from the > parties involved with creating the mock-up. Another criticism--not mine--was > the 90 degree rotated text for category naming. I didn't see a response to > that either. Communication needs to be two-way. > > [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/ This is pretty far off topic. I think discussing a control center design is really important. But it should probably happen here: http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On vr, 2009-07-24 at 10:18 -0700, Sandy Armstrong wrote: > On Fri, Jul 24, 2009 at 9:41 AM, Andre Klapper wrote: > > Am Freitag, den 24.07.2009, 10:59 -0500 schrieb Mike Kestner: > >> Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch > >> for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. > >> The 2.12 branch should be used for future 2.x builds. > >> > >> trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a > >> message to d-d-l if/when they switch to 3.0. > > > > Does this actually mean that cleanup bugs like > > http://bugzilla.gnome.org/show_bug.cgi?id=580422 or > > http://bugzilla.gnome.org/show_bug.cgi?id=587320 > > that require GTK API that was introduced after GTK 2.12 cannot be fixed > > before GTK3 gets released? > > > > If so this totally blocks GTK3 readiness for applications that depend on > > gtk-sharp I assume? > > Well, as stated in at least the Tomboy bug above, we should be able to > work around this even if we are using gtk-sharp 2.12. We can just > DllImport the new API ourselves. F-Spot has a project on gitorious > (called gtk-sharp-beans, I think) where they maintain a few post-2.12 > pieces of API that they use, so gtk-sharp being stuck on 2.12 is not > too big a hindrance for us. That is correct, F-Spot uses a module called gtk-sharp-beans [1] which adds the API needed to overcome the fact that gtk-sharp is stuck at 2.12. The gio-sharp module [2] serves the same purpose, for GIO. [1]: http://gitorious.org/gtk-sharp-beans [2]: http://gitorious.org/gio-sharp -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 10:18 AM, Sandy Armstrong wrote: > On Fri, Jul 24, 2009 at 9:41 AM, Andre Klapper wrote: >> Am Freitag, den 24.07.2009, 10:59 -0500 schrieb Mike Kestner: >>> Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch >>> for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. >>> The 2.12 branch should be used for future 2.x builds. >>> >>> trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a >>> message to d-d-l if/when they switch to 3.0. >> >> Does this actually mean that cleanup bugs like >> http://bugzilla.gnome.org/show_bug.cgi?id=580422 or >> http://bugzilla.gnome.org/show_bug.cgi?id=587320 >> that require GTK API that was introduced after GTK 2.12 cannot be fixed >> before GTK3 gets released? >> >> If so this totally blocks GTK3 readiness for applications that depend on >> gtk-sharp I assume? > > Well, as stated in at least the Tomboy bug above, we should be able to > work around this even if we are using gtk-sharp 2.12. We can just > DllImport the new API ourselves. F-Spot has a project on gitorious > (called gtk-sharp-beans, I think) where they maintain a few post-2.12 > pieces of API that they use, so gtk-sharp being stuck on 2.12 is not > too big a hindrance for us. > > So to be clear, that Tomboy bug does not block on updates to > gtk-sharp, and is targeted to be fixed by Tomboy developers before > GNOME 2.28. Turns out gtk-sharp-beans already had done the work for me, so I borrowed a file from Stephane and pushed the fix to master. http://bugzilla.gnome.org/show_bug.cgi?id=580422 is now fixed. Glad this came up, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson wrote: > So if it turns out that the GNOME community like the general direction > we've suggested for the control center, then sure, I'd certainly like to see > us widen out the discussion to visual panels as well. Has there been any movement with regard to the mouse-over pop-up menu criticism that I pointed out--that it breaks the metaphor and there's no precedent for it? There wasn't any response on the blog post[1] from the parties involved with creating the mock-up. Another criticism--not mine--was the 90 degree rotated text for category naming. I didn't see a response to that either. Communication needs to be two-way. [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 9:41 AM, Andre Klapper wrote: > Am Freitag, den 24.07.2009, 10:59 -0500 schrieb Mike Kestner: >> Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch >> for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. >> The 2.12 branch should be used for future 2.x builds. >> >> trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a >> message to d-d-l if/when they switch to 3.0. > > Does this actually mean that cleanup bugs like > http://bugzilla.gnome.org/show_bug.cgi?id=580422 or > http://bugzilla.gnome.org/show_bug.cgi?id=587320 > that require GTK API that was introduced after GTK 2.12 cannot be fixed > before GTK3 gets released? > > If so this totally blocks GTK3 readiness for applications that depend on > gtk-sharp I assume? Well, as stated in at least the Tomboy bug above, we should be able to work around this even if we are using gtk-sharp 2.12. We can just DllImport the new API ourselves. F-Spot has a project on gitorious (called gtk-sharp-beans, I think) where they maintain a few post-2.12 pieces of API that they use, so gtk-sharp being stuck on 2.12 is not too big a hindrance for us. So to be clear, that Tomboy bug does not block on updates to gtk-sharp, and is targeted to be fixed by Tomboy developers before GNOME 2.28. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
Am Freitag, den 24.07.2009, 10:59 -0500 schrieb Mike Kestner: > Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch > for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. > The 2.12 branch should be used for future 2.x builds. > > trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a > message to d-d-l if/when they switch to 3.0. Does this actually mean that cleanup bugs like http://bugzilla.gnome.org/show_bug.cgi?id=580422 or http://bugzilla.gnome.org/show_bug.cgi?id=587320 that require GTK API that was introduced after GTK 2.12 cannot be fixed before GTK3 gets released? If so this totally blocks GTK3 readiness for applications that depend on gtk-sharp I assume? andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
The perception, at least from me personally, is that Sun isn't doing a very good job at *working* with the GNOME community. Case in point, if RBAC or Visual Panels are oh-so-much-better, why the heck are you guys not trying to push it for non-Linux? I can't speak for RBAC, but re Visual Panels, the control center ideas that Sun has been publicly kicking around since GUADEC are actually intended a first step along the way towards a migration to Visual Panels over time, for OpenSolaris at least. Whether or not anyone outside of Sun has any interest in VP isn't really something we've tested the waters with yet, partly because it was initially intended as a project to provide GUI configuration for Solaris SMF services (I think the scope has widened a bit since then, though), and partly because Visual Panels themselves have mostly been written in Java up to now. Neither of those make it an immediately-obvious candidate for widespread adoption, but I'm sure they're not insurmountable either. So if it turns out that the GNOME community like the general direction we've suggested for the control center, then sure, I'd certainly like to see us widen out the discussion to visual panels as well. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.ben...@sun.comOpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Visible control to toggle icons in buttons
On 07/24/2009 05:55 PM, A. Walton wrote: On Fri, Jul 24, 2009 at 11:29 AM, Stefan Kost wrote: Calum Benson schrieb: On 22 Jul 2009, at 11:23, Luca Ferretti wrote: As all you may know, we recently switched to a "no icons" approach in both menus[1] and buttons[2]. Currently the Appearance capplet provides a checkbox to toggle icons in menus. Should we (re)add a checkbox for buttons too? Maybe users that really want icons on their buttons could appreciate more a checkbox then open gconf-editor or run gconftool :) Since the decision has been made to go down this route, I'd be more inclined to ask if we wanted to remove the checkbox to toggle icons in menus... but either way, I guess it would make sense to be consistent. While I personally won't miss the icons in button too much, I like to keep them in my menus. I can only echo this. On my system when the icons are gone from menus, the menus still look as if there /should/ be icons there, only they're not, which is really ugly. See http://file.status.net/identica/awalton-20090719T110853-tltvv6t.png. If that indenting could be fixed it probably wouldn't look so alien, but as it stands, it's horrible. I've been running a gtkrc to remove button images for ages though, so I really won't miss those. Hi! The indention is there to give space for checks and radio buttons, even if the menu in question don't sport one. If it didn't do that, menus with controls in them would look different from those without. The example in your screenshot is a exception from the guidelines, as it's showing applications. Jon made a patch for that already. http://bugzilla.gnome.org/show_bug.cgi?id=322932 - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Visible control to toggle icons in buttons
On Fri, Jul 24, 2009 at 11:55 AM, A. Walton wrote: > On Fri, Jul 24, 2009 at 11:29 AM, Stefan Kost wrote: > I can only echo this. On my system when the icons are gone from menus, > the menus still > look as if there /should/ be icons there, only they're not, which is > really ugly. > > See http://file.status.net/identica/awalton-20090719T110853-tltvv6t.png. > > If that indenting could be fixed it probably wouldn't look so alien, > but as it stands, it's horrible. > I've been running a gtkrc to remove button images for ages though, so > I really won't miss those. I guess 'de gustibus non est disputandum', but everybody I've discussed this with so far considered the consistent spacing (regardless of the presence/absence of icons, toggles, checks, whatnot) a big plus. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, 2009-07-24 at 08:01 -0700, Sandy Armstrong wrote: > On Fri, Jul 24, 2009 at 7:15 AM, Frederic Peters wrote: > > Sandy Armstrong wrote: > > > >> Talking to Jeff Stedfast, this is most likely caused by using gtk# > >> trunk in jhbuild. Although this will surely be fixed, we recommend > >> switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 > >> branch in SVN, which is still maintained). > > > > What about gnome-sharp ? Is it ok to follow trunk ? Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. The 2.12 branch should be used for future 2.x builds. trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a message to d-d-l if/when they switch to 3.0. -- Mike Kestner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Visible control to toggle icons in buttons
On Fri, Jul 24, 2009 at 11:29 AM, Stefan Kost wrote: > Calum Benson schrieb: >> >> On 22 Jul 2009, at 11:23, Luca Ferretti wrote: >> >>> As all you may know, we recently switched to a "no icons" approach in >>> both menus[1] and buttons[2]. >>> >>> Currently the Appearance capplet provides a checkbox to toggle icons >>> in menus. >>> >>> Should we (re)add a checkbox for buttons too? Maybe users that really >>> want icons on their buttons could appreciate more a checkbox then open >>> gconf-editor or run gconftool :) >> >> Since the decision has been made to go down this route, I'd be more >> inclined to ask if we wanted to remove the checkbox to toggle icons in >> menus... but either way, I guess it would make sense to be consistent. > While I personally won't miss the icons in button too much, I like to > keep them in my menus. I can only echo this. On my system when the icons are gone from menus, the menus still look as if there /should/ be icons there, only they're not, which is really ugly. See http://file.status.net/identica/awalton-20090719T110853-tltvv6t.png. If that indenting could be fixed it probably wouldn't look so alien, but as it stands, it's horrible. I've been running a gtkrc to remove button images for ages though, so I really won't miss those. -A. Walton > So please don't remove that. I seems to also have > totally missed the *discussion* that lead to the *decission* that *we* > want to remove the icons. With all due respect, I still feel like the > major advantage is that the art team has to draw less icons (I am not > saying that you are lazy, you do a great job). > > Stefan > >> >> Cheeri, >> Calum. >> > > ___ > 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: Visible control to toggle icons in buttons
Calum Benson schrieb: > > On 22 Jul 2009, at 11:23, Luca Ferretti wrote: > >> As all you may know, we recently switched to a "no icons" approach in >> both menus[1] and buttons[2]. >> >> Currently the Appearance capplet provides a checkbox to toggle icons >> in menus. >> >> Should we (re)add a checkbox for buttons too? Maybe users that really >> want icons on their buttons could appreciate more a checkbox then open >> gconf-editor or run gconftool :) > > Since the decision has been made to go down this route, I'd be more > inclined to ask if we wanted to remove the checkbox to toggle icons in > menus... but either way, I guess it would make sense to be consistent. While I personally won't miss the icons in button too much, I like to keep them in my menus. So please don't remove that. I seems to also have totally missed the *discussion* that lead to the *decission* that *we* want to remove the icons. With all due respect, I still feel like the major advantage is that the art team has to draw less icons (I am not saying that you are lazy, you do a great job). Stefan > > Cheeri, > Calum. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 7:15 AM, Frederic Peters wrote: > Sandy Armstrong wrote: > >> Talking to Jeff Stedfast, this is most likely caused by using gtk# >> trunk in jhbuild. Although this will surely be fixed, we recommend >> switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 >> branch in SVN, which is still maintained). > > What about gnome-sharp ? Is it ok to follow trunk ? Probably; I'm not sure. Same question applies to gnome-desktop-sharp, too. CC'ing Mike Kestner, who should have a better idea of what to recommend. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Thu, 2009-07-23 at 04:58 -0500, Brian Cameron wrote: > Sun is already working to add DeviceKit support to Solaris It would be good to the devkit-devel mailing list know about this. Because if this is so, we need to change some of our plans; in particular move the "make porting easier" up the priority list. Also, I hope you guys know that PolicyKit is a not an optional dependency. Either way, even if you didn't want to contribute to DeviceKit-disks or DeviceKit-power, you can always just ship your own GVolumeMonitor implementation in a GIO module [1] and patch/reimplement g-p-m to use whatever. As I said in other mails, I don't think we ever want the core G stack to depend on something that only exists for Linux. [1] : This GVolumeMonitor implementation could probably use the same codebase as your excellent Fishworks product. > Sun does not have much of > an interest in shipping modules which have a strong dependency on > PolicyKit No-one ever explained to me why Sun is suddenly not interested in this - and SUN did send patches to PolicyKit earlier on. The only explanations I've seen (in private mails) included childish statements like claiming PolicyKit is "rubbish" and that the author, me, didn't know what I was doing. Anyway, maybe you should ask someone at Sun out the latest polkit version http://hal.freedesktop.org/docs/polkit/ which is a complete rewrite of the old code. PolicyKit, by itself, is now merely an interface to interface to the authorization system - adding support for a Solaris RBAC backend amounts to subclassing a single class, implementing two methods and drop that code in an .so in $libdir/polkit-1/extensions. Yes, you're welcome that it is now this easy. > (e.g. Sun is moving to use VisualPanels instead of wanting > to ship GNOME system tools), and it typically isn't hard to make those > few programs that use PolicyKit that we do want to ship use RBAC > instead. Uh, RBAC just _doesn't_ do what a modern desktop needs. At least not last time I checked. The problem with Solaris RBAC, like many other authorization frameworks out there (I did an extensive analysis of many different authz frameworks some time ago), is that they really are not designed with the modern desktop in mind. Case in point, last time I checked out OpenSolaris (about a year ago so things might have changed) the whole package manager UI was a single process running as uid 0. Not only does this violate very fundamental security principles (least privilege etc.), it also messes up the user interface (theming, file chooser (root's home) etc.). And if you want a11y to work with such programs, then you effectively just extended uid 0 privileges to the rest of the desktop session. > I am not sure what the big deal is here. Nobody from Sun has been > complaining about GNOME being too Linux-ey, have they? Sun has always > had a good relationship with the GNOME community, and it has never been > particularly hard to get patches upstream to support things needed for > GNOME to work well on Solaris or OpenSolaris. The perception, at least from me personally, is that Sun isn't doing a very good job at *working* with the GNOME community. Case in point, if RBAC or Visual Panels are oh-so-much-better, why the heck are you guys not trying to push it for non-Linux? And actually do the integration work inside GNOME instead of bolting your work on after the fact? That would benefit both Sun, the rest of the GNOME community and it would make you guys look a lot better. At least in my eyes. Btw, if you look at the Linux kernel community, behavior like this is frowned upon. So I don't think you should be too surprised that this is how some of us feels. Anyway, didn't mean to sound rude or too harsh, hope you guys will take this as constructive criticism. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
Sandy Armstrong wrote: > Talking to Jeff Stedfast, this is most likely caused by using gtk# > trunk in jhbuild. Although this will surely be fixed, we recommend > switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 > branch in SVN, which is still maintained). What about gnome-sharp ? Is it ok to follow trunk ? Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 4:26 AM, Luca Ferretti wrote: > 2009/7/24 Bastien Nocera : >> Heya, >> >> Yesterday I've replaced the RSS Podcast date parsing in totem-pl-parser >> to use GMime instead of evolution-data-server's libcamel, which should >> make it easier to build, and be lighter for dependencies. >> >> We require gmime-2.4, which is the current stable version. >> > > For the record, in jhbuild gmime fails to build C# bindings Talking to Jeff Stedfast, this is most likely caused by using gtk# trunk in jhbuild. Although this will surely be fixed, we recommend switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 branch in SVN, which is still maintained). I am not aware of any schedule indicating a release of gtk# from trunk by GNOME 2.28 (but I could be wrong). Hope this helps, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
2009/7/24 Bastien Nocera : > Heya, > > Yesterday I've replaced the RSS Podcast date parsing in totem-pl-parser > to use GMime instead of evolution-data-server's libcamel, which should > make it easier to build, and be lighter for dependencies. > > We require gmime-2.4, which is the current stable version. > For the record, in jhbuild gmime fails to build C# bindings /opt/gnome2/bin/mcs -unsafe /out:gmime-sharp.dll /target:library -r:/opt/gnome2/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll -r:/opt/gnome2/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll -r:/opt/gnome2/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll -r:/opt/gnome2/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll -r:/opt/gnome2/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll \ -keyfile:./gmime-sharp.snk ./StreamWrapper.cs AssemblyInfo.cs generated/*.cs generated/GMimeSharp.HeaderWriterNative.cs(10,10): error CS0246: The type or namespace name `UnmanagedFunctionPointer' could not be found. Are you missing a using directive or an assembly reference? ** (/opt/gnome2/lib/mono/1.0/mcs.exe:12233): WARNING **: Missing method .ctor in assembly /opt/gnome2/lib/mono/gac/glib-sharp/2.14.0.0__35e10195dab3c99f/glib-sharp.dll, type System.Runtime.InteropServices.UnmanagedFunctionPointerAttribute ** (/opt/gnome2/lib/mono/1.0/mcs.exe:12233): WARNING **: The class System.Runtime.InteropServices.UnmanagedFunctionPointerAttribute could not be loaded, used in glib-sharp ** (/opt/gnome2/lib/mono/1.0/mcs.exe:12233): WARNING **: Can't find custom attr constructor image: /opt/gnome2/lib/mono/gac/glib-sharp/2.14.0.0__35e10195dab3c99f/glib-sharp.dll mtoken: 0x0ad2 Unhandled Exception: Mono.CSharp.InternalErrorException: generated/GMimeSharp.HeaderWriterNative.cs(13,24): GMimeSharp.HeaderWriterInvoker ---> Mono.CSharp.InternalErrorException: generated/GMimeSharp.HeaderWriterNative.cs(17,36): GMimeSharp.HeaderWriterInvoker.__notify ---> System.TypeLoadException: Could not load type 'System.Runtime.InteropServices.UnmanagedFunctionPointerAttribute' from assembly 'glib-sharp'. at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x0] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x0] at System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x0] at Mono.CSharp.AttributeTester.GetObsoleteAttribute (System.Type type) [0x0] at Mono.CSharp.Expression.ResolveAsTypeTerminal (IResolveContext ec, Boolean silent) [0x0] at Mono.CSharp.MemberBase.ResolveMemberType () [0x0] at Mono.CSharp.MemberBase.Define () [0x0] at Mono.CSharp.Field.Define () [0x0] at Mono.CSharp.TypeContainer+MemberCoreArrayList.DefineContainerMembers () [0x0] --- End of inner exception stack trace --- at Mono.CSharp.TypeContainer+MemberCoreArrayList.DefineContainerMembers () [0x0] at Mono.CSharp.TypeContainer.DefineContainerMembers (Mono.CSharp.MemberCoreArrayList mcal) [0x0] at Mono.CSharp.Class.DefineContainerMembers (Mono.CSharp.MemberCoreArrayList list) [0x0] at Mono.CSharp.TypeContainer.DoDefineMembers () [0x0] at Mono.CSharp.Class.DoDefineMembers () [0x0] at Mono.CSharp.TypeContainer.Define () [0x0] at Mono.CSharp.ClassOrStruct.Define () [0x0] at Mono.CSharp.Class.Define () [0x0] at Mono.CSharp.RootContext.PopulateTypes () [0x0] --- End of inner exception stack trace --- at Mono.CSharp.RootContext.PopulateTypes () [0x0] at Mono.CSharp.Driver.Compile () [0x0] at Mono.CSharp.Driver.Main (System.String[] args) [0x0] make[2]: *** [gmime-sharp.dll] Errore 1 make[2]: uscita dalla directory «/home/betatester/checkout/gnome2/gmime-2.4.7/mono» make[1]: *** [all-recursive] Errore 1 make[1]: uscita dalla directory «/home/betatester/checkout/gnome2/gmime-2.4.7» make: *** [all] Errore 2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GMime as an external dependency
Heya, Yesterday I've replaced the RSS Podcast date parsing in totem-pl-parser to use GMime instead of evolution-data-server's libcamel, which should make it easier to build, and be lighter for dependencies. We require gmime-2.4, which is the current stable version. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
