Re: Feature proposal: combined system status menu
El 22/04/13 18:57, Allan Day escribió: > Federico Mena Quintero wrote: >> On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: >> * Unsuitability of 16x16px icons on touch screens >> >> "So make them larger" :) > > And make the bar taller in the process? I don't think that people > would thank us for that. > >> Seriously, this is not just for touch screens. Those need big targets. > > The target is the height of the bar. > > >> Summary - maybe bigger icons, or just contrastier ones? Use a wider top >> bar for touch screens? >> >> * Large width of items in the System Status area (including the user's >> name) taking up too much space in portrait mode >> >> How much is too much space? Do you have a screenshot that shows the >> problem? >> >> I have a long name but fortunately a 1600 pixel-wide screen. When I >> used gnome-shell on a 1024 pixel netbook it felt a bit cramped, but it >> was not a huge problem. Maybe if the user's full name gets over a >> certain percentage of the screen's width, then gnome-shell should switch >> to showing just the Unix username? > > This primarily relates to portrait mode (there's a bug for this [1]), > but it could potentially affect any user if they have a smallish > screen and a super long name. > Hi ! >From my point of view, the root of the problem comes from the touch screen dimensions (both pixels and physical size) and maybe finger size :P What about a split/combine option for the status menus. I mean, we can define when a combined menu makes sense (small touch screens or portrait mode) and when splitted menus are best suitable (bigger touch screens or non touch screen screen for example). And this can be tweaked by the user someway. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.10 Feature: Integrate Zimbra in GNOME
Zimbra and Alfresco support are good features to promote GNOME as corporate Desktop. Cheers, -- Juanjo Marin On 10/04/13 03:20, Sriram Ramkrishna wrote: > I would love to see Alfresco support if possible, although it can be > supported using just plain ol webdav. I have a contact for this if > you're interested in regards to useful api etc. > > sri > > > > On Tue, Apr 9, 2013 at 5:23 PM, Debarshi Ray <mailto:rishi...@lostca.se>> wrote: > > I would like to propose the following feature for 3.10: > Integrate Zimbra in GNOME > https://live.gnome.org/ThreePointNine/Features/Zimbra > > We already have most of the pieces of the puzzle (IMAP/SMTP, > CalDAV, CardDAV) > in place, so it is a matter of tying them up together and letting > users have a > single point of contact for adding their Zimbra accounts. > > Currently one has to separately add their email, calendar and > address book in > Evolution and Evolution Data Server, which is a bit suboptimal. > > Happy hacking, > Debarshi > > > -- > If computers are going to revolutionize education, then steam > engines and cars > and electricity would have done it too. -- Arjun Shankar > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org <mailto:desktop-devel-list@gnome.org> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Juan José Marín Martínez Tlf: 956009437 (Corp. 409437) Móvil: 671596200 (Corp. 696200) Fax: 956009445 (Corp. 409445) Centro de Proceso de Datos. Delegación Territorial de Educación, Cultura y Deporte en Cádiz Consejería de Cultura y Deporte. Junta de Andalucía Antes de imprimir este correo electrónico piense bien si es necesario hacerlo: El medioambiente es cosa de todos. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Thu, 2011-04-28 at 18:38 -0400, Colin Walters wrote: > On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters wrote: > > > > == Dynamic Languages in GNOME == > > > > One thing that's worth addressing though (again) is the question "do > > we need both Python and JavaScript?". The uptake of both seed and gjs > > has been relatively low; lower than Python at least for scripting > > GNOME apps. However, I think at least one the core reason for working > > on JavaScript remains that *we define the platform*. > > Actually I've been thinking about this more, and I am changing my > mind; if we don't have an immediate plan for making JavaScript more > compelling, and there's still active people maintaining Python, we > should be advertising the latter, and not the former. > > So here's what I propose (and I'm willing to write patches, but mostly > this is just marketing/messaging): > > * Officially mark both gjs and seed as experimental (this is the > reality as it is for 3.0 anyways) > * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just > gnome-games/lightsoff?) using C/Vala/gtkmm/Python > * Remove /usr/bin/gjs > * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and > no - porting to Python would be a pointless waste of time at best) > > What does this mean about the JavaScript future? My take here is that > for 3.2 at least, we could move it more towards being an "embedding" > language, designed from the very start to be used in a split C/JS > role. Also, this allows us flexibility to evolve JavaScript and > return later with something more interesting. For example, a combined > WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two > different attempts at. > I think that GNOME has the aspiration of being a multilanguage platform since its conception. We should keep in mind that allowing access to C objects from other languages was one of the major design goals. The latest addition of Vala and Javascript to our language toolset is very convenient because it makes easier to develop specifically for our platform. However, we should keep working on making all our API is fully accessible (GObject Introspection is big step in this direction) and help programmers to use it right using other popular languages. That said, I think Javascript and CSS-styling styling is very good move because it gives the impression of adopting web standards in the desktop. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no way to change theme or fonts in System Settings?
El jue, 17-03-2011 a las 10:55 +, Allan Day escribió: > On Thu, 2011-03-17 at 11:15 +0100, Dave Neary wrote: > > Hi, > > > > Jasper St. Pierre wrote: > > > The story I've heard is that we haven't supported themes because we > > > make no guarantees about CSS class stability: CSS support was a nifty > > > thing that was added so that we could put up a couple actors and mold > > > them like clay into our mockups very quickly and easily. With the > > > gnome 3 release, I doubt we'll add have a theme switcher out of the > > > box. > > > > > > We've accepted patches to add API to make it easier for people making > > > third-party theme switchers: SardemFF7 has one, a random guy from > > > deviantart (not half-left) has another, and there's also > > > gnome-plumbing and gnome-tweak-tool. > > > > Thanks for the info, Jasper! Is there a blessed/recommended tweak tool > > that people should be suggesting when we get asked these questions? > > gnome-plumbing never existed. I would point people to John's > gnome-tweak-tool. > > Note: I don't think we should be 'recommending' such a tool as a part of > the GNOME 3 experience. GNOME 3 is great as is, and people shouldn't > need to change it. If they desperately want to tweak, they can, of > course; and John has provided an easy way to do it (go John!) I agree, but IMHO, it is common for users to change the theme, so, even without promoting it, a lot of users will be using this tweaking tool if it is the only way for do it. For me tweaking is changing parameters that it is tought that users shouldn't change, but I find strange the only way to change the theme/fonts is through tweaking :) Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Question about GNOME 3.0 bindings plans
Thanks for the quick reply On Fri, 2011-01-21 at 18:31 +0100, Andre Klapper wrote: > > AFAIK, one of the cornerstone components of GNOME 3 is GObject > > Introspection. I'd like to know which libraries are supposed to > > support GObject Introspection. > > http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport has a > list, not necessarily up-to-date. OK, so it seems _all_ the GNOME APIs will have GObject Introspection support. > > Another question is which bindings/language will be officially endorsed > > by the GNOME project. > > The new, yet-to-release developer.gnome.org will focus on C, C++, > Python, Javascript, and Vala. So does this mean that all the APIs will have bindings for C++, Python, Javascript and Vala ? [Sorry if this ia a stupid question] Are all these bindings will be gobject introspected bindings ? > > Being an outsider to the binding stuff, the information I've found is > > pretty confusing. For example, the relationship between PyGi/PObject > > Introspection and PyGTK. > > See the header of http://live.gnome.org/PyGTK . OK, so PyGTK is the depecrated binding of the GTK+ library. It has been dropped in favor of PyObject. So... - From http://live.gnome.org/PyGObject I've got it includes the GLib/GObject/GIO Python bindings - http://live.gnome.org/PyGTK means it includes the GTK+ bindings - What about other GNOME stack elements, it is taken by granted you have bindings ? TIA, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Question about GNOME 3.0 bindings plans
Hi, AFAIK, one of the cornerstone components of GNOME 3 is GObject Introspection. I'd like to know which libraries are supposed to support GObject Introspection. Another question is which bindings/language will be officially endorsed by the GNOME project. Being an outsider to the binding stuff, the information I've found is pretty confusing. For example, the relationship between PyGi/PObject Introspection and PyGTK. Thanks in advance, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel & gnome-applets?
On Thu, 2010-12-23 at 15:01 -0600, Jason D. Clinton wrote: > On Thu, Dec 23, 2010 at 12:54, Carlos Garcia Campos > wrote: > I disagree. If I run gnome-session with the classic mode I > expect to > see exactly what I have right now, with all the applets. The > definition of essential applet is probably different for every > user. > > I am not a designer but I've been paying attention to this process for > about 1.5 years now so I think I can address your concerns. > > We are on the path of ending the insanity of behavior customization > with GNOME 3 (though all are welcome to help with the maintenance of > the gnome-applets module, of course.) Obviously, personalization is > staying (wallpaper, themes, cursors, sounds, preferences). In GNOME 3, > the objective is create a desktop that actually works out of the box; > one that doesn't require that you help your family members fiddle with > a bunch of settings before it's a tolerable experience. (For example, > the very first thing I kill is the workspace switcher and show desktop > applets because no family member can comprehend looking at them to > figure out where all their windows just went after they accidentally > click them. In Shell these are replaced with the same features but in > a way which has an actual usable UI.) > > This means stopping the abuse of applets which in some cases are > stand-ins for something that should be a "desktop widget" (Finance and > Deskbar, for example)[1] and in other cases are horrible hacks that > try to "fix" bad design elsewhere in the OS (battery charge applet > predates g-p-m, for example). Others are just a pointless toys which > are maintenance burden. In most cases the outcome will be that some > combination of the legacy notification area icons and essential > applets will provide access to hardware-related and session-related > functions in the order and locations they located in the Shell design. > Clearly, network, keyboard, power, a11y, sound, bluetooth, system, > applications and clock are staying. Probably launchers. Places is a > long-term unknown. There are going to be others; the list is still a > work in-progress. > > GNOME 2 fallback experience should be gnome-panel, metacity > and > gnome-applets. > > It's a fallback but it's also going in to long-term maintenance mode > which means we need to have a coherent experience between the > "compatible" and Shell desktop environments. And they need to continue > to adapt to API changes. Try to imagine the next major vertical > hardware integration to come along, say, for example, that we get a > desktop-wide, WiFi supported, geolocation API with privacy guards. Now > we have to write a geolocation indicator and UI for both shells. (Just > speculating.) > > We're planning for the future here and for one in which everyone has a > good experience without having to muck around. Though I agree that we must planning the future, we also need to give a migration path for our users. There are big deployments out there, and sometimes they need _time_ for evaluating the new features, updating their hardware if necessary, adapting their configurations, etc. I think that it is even a good idea to give a maintenance promise for a specific period of time for gnome-panel, metacity and gnome-applets. But, talk is cheap and I don't know if we as a project can made this promise. Just my two cents, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Another build status update
El jue, 16-12-2010 a las 10:03 +0100, Murray Cumming escribió: > On Wed, 2010-12-15 at 11:06 -0500, Matthias Clasen wrote: > > gtkmm (seems to have problems with GdkPixbufFormat) > > Could you give me more details, please. This is the first I've heard of > it, and I'm working almost every day to keep gtkmm building against GTK+ > from git master. > Hi Murray, I think Matthias is talking about the problems on some jhbuild clients. Take at look to http://build.gnome.org/gtkmm The good news is there is a one without any problem Cheers, -- Juanjo Marin -- Juan José Marín Martínez Tlf: 956009437 (Corp. 409437) Móvil: 671596200 (Corp. 696200) Fax: 956009445 (Corp. 409445) Informática. Consejería de Cultura. DP Cádiz. Junta de Andalucía Antes de imprimir este correo electrónico piense bien si es necesario hacerlo: El medioambiente es cosa de todos. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build status
On Wed, 2010-12-08 at 07:23 -0500, Matthias Clasen wrote: > Here is a quick analysis of the status of builds on build.gnome.org. > The one-line summary is that getting webkit and e-d-s to build against > current GTK+ will get us quite a bit closer to a fully building tree. > But there is also a bunch of easy fixes for make check failures. > > Matthias > > > 183 modules > 162 built ok 88% > 131 checked ok 72% > > Stuff that doesn't build > > Doesn't build with gtk3: > evolution-data-server > networkmanager-applet > gtkhtml > webkit > gtkmm > gtk-vnc > > Needs webkit: > empathy > epiphany > yelp > devhelp > > Needs e-d-s: > evolution > empathy > ekiga > > Other problems: > bluez (autofoo/jhbuild problems) > accountsservice (autofoo problems) > tracker (needs newer dbus) > gnome-system-monitor (needs gtkmm) > anjuta (introspection) > vinagre (needs gtk-vnc) > gtk-sharp > pygtk > tomboy > > Stuff that fails in make check: > > Needs POTFILES.in update: > pulseaudo > gnome-control-center > polkit-gnome > gnome-session > totem > gedit > > Needs a display to run tests: > clutter > > Needs some other service to run tests: > gst-plugins-good (gconf) > > Random extra dependencies for make check: > telepathy-mission-control (needs twisted.internet) > evince (dogtail) Evince also needs a line to be added POTFILES.in (waiting for commit - bgo 636768) dogtail is only in the gnome-world-3.0 moduleset. I wonder if we should add it in another moduleset to get the test done. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I cant build mozilla external dependency with jhbuild
El mar, 26-10-2010 a las 17:21 +0200, Javier Jardón escribió: > mozilla (needed by gnome-shell) can't be builded because the version > in moduleset (1.9.1.11) is no longer > available in mozilla ftp repos: > http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/ > > Should be updated to 1.9.1.14 or maybe 1.9.2.10 ? > I recommend you to follow the instructions for building from http://live.gnome.org/GnomeShell The shell script linked http://git.gnome.org/browse/gnome-shell/plain/tools/build/gnome-shell-build-setup.sh doesn't build mozilla-xulrunner from code, it installs a package instead it installs mozilla-xulrunner191 for opensuse, but the current ubuntu xulrunner-dev version seems to be 1.9.2.10 I hope this helps you, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince needs shared_mime_info
On Thu, 2010-10-21 at 18:34 +0100, Bastien Nocera wrote: > On Thu, 2010-10-21 at 19:07 +0200, Juanjo Marin wrote: > > Hi, > > > > Compiling Evince with jhbuild I've realised that it doesn't build > > shared_mime_info. Evince uses gtk_recent_info_get_mime_type() and > > g_content_type_from_mime_type() functions in order to detect the type of > > files it handles. So, Evince needs access the share_mime_info database > > and I think it should be added as a dependency in jhbuild. > > shared-mime-info should already be a dependency of glib, because of GIO. > Otherwise we could add the dependency to half of the modules in the > module sets. I'm using the moduleset gnome-suites-3.0 and it seems that it isn't neither a glib dependency. I'm missing something ? $ jhbuild list glib libxml2 libgpg-error libgcrypt libxslt intltool rarian gnome-common gnome-doc-utils gtk-doc glib TIA, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince needs shared_mime_info
Hi, Compiling Evince with jhbuild I've realised that it doesn't build shared_mime_info. Evince uses gtk_recent_info_get_mime_type() and g_content_type_from_mime_type() functions in order to detect the type of files it handles. So, Evince needs access the share_mime_info database and I think it should be added as a dependency in jhbuild. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets and GNOME 3
On Tue, 2010-09-28 at 23:36 -0400, Andrew Cowie wrote: > On Tue, 2010-09-28 at 14:09 +0100, Richard Hughes wrote: > > > I thought we were going to distribute gnome panel and applets for some > > > cycles before dropping them out. > > > > If that's the plan, then we need some kind of time limit, and we need > > to build the old libraries with gtk3 [world of pain]. > > I know some people did some work to do a DBus based, rather than Bonobo > based, libpanel-applet. How does that figure into the equation? > Carlos Garcia Campos blogged about this: "The bonobo-less gnome-panel branch was merged into master, so since version 2.31.2 gnome-panel doesn't depend on bonobo anymore. The API is mostly the same, but there are some minor changes since the old API exposed bonobo stuff. This of course means that applets need to be ported to the new API. There's already a GNOME Goal with a porting guide, and I already ported most of the gnome-applets so there are a few examples too." http://carlosgc.linups.org/gnome/libpanel-applet3.html -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets and GNOME 3
El mar, 28-09-2010 a las 12:32 +0100, Richard Hughes escribió: > Okay, we all know applets are a naughty word with GNOME 3. What do we > do with them - delete them from git master? Would this be a > precondition on an project getting the badge of "GNOME 3" ? > I thought we were going to distribute gnome panel and applets for some cycles before dropping them out. -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
On Mon, 2010-07-05 at 17:18 +0200, Vincent Untz wrote: > Le lundi 05 juillet 2010, à 10:48 -0400, Ryan Lortie a écrit : > > hi Everyone, > > > > I recently received an email from a company in our ecosystem asking me > > to relicense a smallish piece of code from GPLv3 to (L)GPLv2. > > > > I'm not really interested in inciting a flamewar on the topic or > > anything, but I'm wondering how people feel, in general about the > > licensing direction of the GNOME project. > > > > > > 1) Go freedom-warrior GPLv3 style and make the world a better place > > (potentially at the cost of our own relevance). > > > > > > 2) Be pragmatic GPLv2 style and make the world a better place > > (potentially at the cost of reduced end-user freedoms). > > > > > > One thing in particular I want to mention is that I asked about this > > topic a couple of years ago in relation to Gtk and was told at that time > > that we can't reasonably relicense Gtk 2.0 since the licence could > > almost be considered as being part of the API/ABI contract. > > > > We have 3.0 upon us now, so I guess we should make a choice one way or > > another. > > The current (unwritten, afaik) policy is (L)GPLv2+. > > It's worth thinking really hard before moving to LGPLv3 (at least; not > sure about GPLv3): LGPLv3 is incompatible with GPLv2, according to the > FSF; that's a major issue, and, IMHO, this doesn't go well with our > philosophy of having our platform LGPL. > > (see http://gplv3.fsf.org/dd3-faq for the compatibility matrix) Maybe it's a good idea to discuss this issue in detail with Bradley M. Kuhn at GUADEC who will give a talk about GNU licenses v3 http://guadec.org/index.php/guadec/2010/paper/view/127 Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OpenSource Study by the Munich University
On Fri, 2010-04-09 at 20:52 +0200, Christopher Roy Bratusek wrote: > http://www.unipark.de/uc/opensource/ I get the following error: The address which you have entered is not correct. Please check your entry for typing errors. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME SWOT Analysis
Hi ! On the public IRC Board of Directors meeting [1] was disscused the topic "Strategic roadmap for GNOME: long term goals". One of the actions agreed was to write a SWOT analysis for generating ideas for strategy and I was charged of this. Here you are the document [2]. I've tried to get together all the concerns about the GNOME project I've found everywhere. This kind of documment is a high level one, not technical. I think a good starting point for defining the strategy lines. So now we can start to discuss the actions we can affort to improve the situation. There are a few on going efforts on areas where SWOT analysis points to. Please, relink existing efforts into the action plan with its status, roadmaps, etc. There are a lot of development-related stuff that I think it is worth to be discussed on this list. I'm going to send a message like this to the marketing-list and the foundation-list as well, so, if you want to discuss something about marketing or more general issues go to these lists instead. Of course, it is impossible to improve everything at once, so there will be areas where we can focus on the near future and other ones will be left for later. After that, we will write a document about the strategic lines we are working. I think it is a s good idea to find a person to be in charge of the evolution of every strategic line. There are some open issues about the management of the strategic lines that I hope we can discuss now (if we need to define a strategy-making body, when we have to evaluate again the situation, how to sync the strategic lines with our releases, etc). Best regards, -- Juanjo Marin [1] http://live.gnome.org/FoundationBoard/Minutes/IRC20100227 [2] http://live.gnome.org/SWOT ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
