Re: GNOME Shell browser plugin
Michael Catanzaro <mcatanz...@gnome.org> writes: > On Fri, 2015-11-06 at 16:05 +0100, Carlos Garcia Campos wrote: >> Are those bugs in WebKit or the plugin itself? > > I don't know. I guess most likely there are bugs in both places, but if > I knew what was wrong I wouldn't be proposing this. The plugin > apparently works fine in Firefox, so there's at minimum some difference > of behavior between WebKit and Firefox. I've been trying it out, and the only problem I've seen is that the plugin module is unloaded by the browser when not used anymore, and reloaded again when needed (for example when navigating). This is not supported by GObject (unless for objects registered dynamically). I've attached a patch to bug #737932 to ensure the module is never unloaded. With the patch applied I have been able to check my installed extensions, configure them, install a new one, enable/disable it and uninstall it. The only think that sometimes didn't work was the enable/disable, that got out of sync between the web ui and the actual state. Reloading the page fixed it, so it looks like a bug somewhere. I guess the reason why it works in firefox is because firefox never unloads the plugins. > Michael -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Shell browser plugin
Sriram Ramkrishna <s...@ramkrishna.me> writes: > On Fri, Nov 6, 2015 at 7:05 AM Carlos Garcia Campos <carlo...@gnome.org> > wrote: > >> Michael Catanzaro <mcatanz...@gnome.org> writes: >> >> >> Let's fix the issues instead, then. >> >> > Michael, myself, Scott and others discussed this at GUADEC. Here are the > minutes from that talk. We had outlined some ways forward that we can > discuss. > > https://wiki.gnome.org/GUADEC/2015/BOFs/GnomeShellExtensions > > I think we will need to figure out how to make this work. Unfortunately, I > could fix the extension breakage this round due to work timeline > pressures. But I will put a process in place next release. As long as the browser plugin solution work, I think the best (and easiest) approach would be to make extensions a pre-installed epiphany web app. > sri -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Shell browser plugin
Michael Catanzaro <mcatanz...@gnome.org> writes: > Hi, > > I am planning to propose blacklisting the GNOME browser plugin in > WebKit, because it has been causing crashes and hangs for several > years, and we don't know how to fix it. My recent commit apparently > didn't help; when we do WebKit updates in Fedora, users regularly > complain in the comments that extensions.gnome.org still causes crashes > or hangs, and we hear this on IRC often as well. I'm planning to > propose making this change effective in WebKitGTK+ 2.12 (March 2016), > so there is time to migrate to something else, but not time to keep > ignoring the issue. Ideally we would not need to do this, and either > fix or delete the plugin in gnome-shell instead. Are those bugs in WebKit or the plugin itself? > This only matters for users running under X11; users running under > Wayland already have no support for NPAPI plugins. Since we're planning > to switch to Wayland by default in Fedora 24, this change would have no > impact on Fedora users: extensions.gnome.org will be broken there (in > Epiphany) no matter what. The gnome-shell plugin doesn't implement NPP_SetWindow(), so I don't see anything incompatible with wayland. I guess we disable plugins at runtime in WebKitGTK+ when connected to a wayland display, but that's something we can change. > Of course, it's bad to break extensions.gnome.org by blacklisting the > plugin, but I'd rather the site be totally broken but Epiphany stable > than the site work sometimes but crash or hang the web process often. > extensions.gnome.org is already broken in Chrome because Chrome got rid > of all NPAPI plugins a while back, and it will soon be broken in > Firefox because Firefox has decided to ban all except Flash by the end > of 2016, so you could see this as incentive to either migrate to > something else (it wouldn't be hard to add the plugin code to Epiphany > itself, but that won't work for Firefox/Chrome) or shut the thing down > before Firefox shuts it down for us. Of course it would be better to switch to any other thing that works on all browsers, but what? > We're going to continue to support other NPAPI plugins in WebKit > indefinitely when running in X11; the GNOME shell plugin is special > only because it's installed by default and causing problems for many > users. Let's fix the issues instead, then. > Michael > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Robert Schroll rschr...@gmail.com writes: On Wed, Oct 15, 2014 at 2:25 PM, Carlos Garcia Campos carlo...@gnome.org wrote: The DOM API is the same in WebKit1 and WebKit2. Not as exposed to Vala, at least. Compare: WebKit1 https://git.gnome.org/browse/vala/tree/vapi/webkit-1.0.vapi#n4632 [1] WebKit2 https://git.gnome.org/browse/vala/tree/vapi/webkit2gtk-web-extension-4.0.vapi#n2409 The v2 API has lost add_event_listener() and gained add_event_listener_with_closure() and remove_event_listener_with_closure(). All those methods are in the gir file generated by WebKit. Robert [1] Admittedly this is the -1.0.vapi, which is rather old. But in Geary, we generate webkitgtk-3.0.vapi, and it has the same methods for EventTarget. Are those VAPI files generated from the gir file? -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpmUplxRZd6n.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Shaun McCance sha...@gnome.org writes: On Wed, 2014-10-15 at 20:30 +0200, Carlos Garcia Campos wrote: Shaun McCance sha...@gnome.org writes: On Tue, 2014-10-14 at 21:17 -0500, Michael Catanzaro wrote: On Tue, 2014-10-14 at 14:44 -0400, Matthias Clasen wrote: On Tue, Oct 14, 2014 at 1:47 PM, Jim Nelson j...@yorba.org wrote: It would be great if the DOM was available via WebKitGTK and the local library did the IPC for us, but I've been told that that's not going to happen. The DOM is a huge API and I can't blame them for that. I do wish the separate process model was an optional run mode because, as I said, I don't see a lot of benefits moving to it for Geary. I think Geary is really the worst-case scenario here: a fairly large application that performs significant DOM manipulations in response to UI events, already written with the WebKit1 API. For apps that are just displaying web pages (everything not geary?) with no such compatibility concerns, porting should be relatively easy. Geary might be worst-case, but Yelp is non-trivial. It does some DOM manipulation, and the whole way it pushes content to WebKit has to be changed. Yelp is easy! :-) We don't actually need to change the way content is pushed to WebKit, I switched the code to use custom uri schemes for the schemes managed by yelp because I thought it was the right way instead of the the current approach of using fake uris. Good to know, thanks. I'll try Real Hard to get that reviewed for 3.16. Thanks! But there is still the issue of the DOM access, as seen in #686376. https://bugzilla.gnome.org/show_bug.cgi?id=686376 Sure, we will need to create a web extension for that, Marcos is working on it. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpxgaM7oCLs6.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Robert Schroll rschr...@gmail.com writes: On Wed, Oct 15, 2014 at 2:36 PM, Evan Nemerson e...@coeus-group.com wrote: Vala is strongly (and statically) typed, so it needs to know what the delegate you pass to the closure argument should look like. GObject Introspection doesn't include that information for for GClosures (bug #636812) so we have to set the type for GClosure arguments in metadata. It's not difficult to do, but someone who actually knows the API needs to tell us what that type should be (or it needs to be documented). The VAPI just needs to change from public bool add_event_listener_with_closure (string event_name, GLib.Closure handler, bool use_capture); to something like public bool add_event_listener_with_closure (string event_name, [CCode (type = GClosure*)] owned WebKit.DOM.FooFunc handler, bool use_capture); I just need to know what to put for instead of WebKit.DOM.FooFunc and I can push a change to the VAPI. Preferably a typedef in C, but if need be we can also create a delegate type from scratch in the VAPI. Thanks for setting me straight on this. I tried to create my own delegate in the VAPI and managed to get it to compile. But it crashed the web process on execution. (As promised, the UI process continued!) So I'm hoping that a WebKitGTK guru can enlighten us on the signature of the delegate. void (* eventListener) (WebKitDOMEventTarget *target, WebKitDOMEvent *event, gpointer user_data); Thanks again, Robert -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgp4W9rNpM7Oi.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Michael Catanzaro mcatanz...@gnome.org writes: On Tue, 2014-10-14 at 14:44 -0400, Matthias Clasen wrote: On Tue, Oct 14, 2014 at 1:47 PM, Jim Nelson j...@yorba.org wrote: It would be great if the DOM was available via WebKitGTK and the local library did the IPC for us, but I've been told that that's not going to happen. The DOM is a huge API and I can't blame them for that. I do wish the separate process model was an optional run mode because, as I said, I don't see a lot of benefits moving to it for Geary. Michael and Robert were sticking their heads together this weekend to see if there is a good way forward for geary's needs. Maybe they can share the results. The easiest way forward would be new WebKit API to allow access to the DOM from the UI process, via a proxy object that automatically routes messages between the UI and web processes. I have no doubt there are good reasons why this API doesn't exist -- probably performance, for one. Carlos? Yes, there are actually several problems with that approach. Forwarding every single DOM method/event to the UI process would mean a lot of IPC traffic, which for sure will affect performance. But more importantly, the DOM API is synchronous, so all of those messages would be blocking both the web and UI processes. The idea is that you can move the logic that needs to access the DOM to the web extension, and then you only communicate to the UI process when needed with the results. That's what we do in epiphany, for example, to implement all the features that require access to DOM. Anyway, Robert and I spent yesterday morning learning how to get a very simple example of UI process - web extension IPC working via D-Bus. (Well, mostly working: Robert discovered today that our example D-Bus signal is broken) The plan was for him to publish the code on GitHub soon. The approach is similar to Epiphany's, but Vala's excellent D-Bus support should allow Geary to avoid a lot of the glue code used in Epiphany. I won't have time to work more on it for the foreseeable future, unfortunately. The current epiphany code was supposed to be a temporary solution, the idea was to use a private dbus connection instead of using the session bus, but in the end we never found the time to do that. I think Geary is really the worst-case scenario here: a fairly large application that performs significant DOM manipulations in response to UI events, already written with the WebKit1 API. For apps that are just displaying web pages (everything not geary?) with no such compatibility concerns, porting should be relatively easy. Evolution is even worse scenario, I would say, but at least is written in C :-) Happy October, Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpS_mdbBFnLT.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Jim Nelson j...@yorba.org writes: Just to jump in, the situation we're facing with Geary is that Geary works fairly intimately with the WebKit DOM. For example, we programmatically inject HTML elements while building the page and even in response to user events after the page has been rendered. In WebKit 1 this was no problem as the entire DOM was available via WebKitGTK. Not sure what you mean by via WebKitGTK, but the exactly same DOM API is available in WebKit2, but only from a Web Extension loaded by the web process. In WebKit 2, the page is rendered by a separate process and the DOM is unavailable to the parent process. As I understand things, we need to write a .so and instruct the rendering process to load it for our HTML. In turn, that .so is in-process and has full access to the DOM. The .so then needs to offer some kind of IPC -- D-Bus would be perfect for this -- that allows for Geary to communicate DOM updates. This is also how we can be informed of user input. Correct. Since we use WebKit to compose mail as well, that's going to have be refactored too, probably with a separate IPC as our needs with the composer are entirely different than the message viewer. This is a major refactoring of Geary. I imagine almost any application that does anything more than displaying static HTML will run into similar problems. In some cases, for simple things it would be possible to use JavaScript, instead of writing a web extension. User scripts can be injected from the UI process with WebKitUserContentManager, you can run any javascript from the UI process with webkit_web_view_run_javascript(), and we are working on an API that allows to post messages from JavaScript that are sent to the UI process and exposed as signals of the user content manager. I should add that the separate process model of safety is not really a big benefit for us. We run with JavaScript and plug-ins disabled. We rarely if ever get WebKit crashes reported to us. Note that the separate process model is not only for safety, but also for performance and responsiveness among other things. I understand porting apps in some cases is a it more painful, though. It would be great if the DOM was available via WebKitGTK and the local library did the IPC for us, but I've been told that that's not going to happen. I don't get what you mean by via WebKitGTK, nor what the local library is. We decided not to provide IPC for the UI and web extensions communication, so that the user can use whatever they want, but also with the idea that if apps end up using mostly the same DBus code, we can eventually add some API. The DOM is a huge API and I can't blame them for that. I do wish the separate process model was an optional run mode because, as I said, I don't see a lot of benefits moving to it for Geary. Hopefully the Geary UI will be more responsive and faster once you switch to WebKit2. -- Jim On Tue, Oct 14, 2014 at 3:24 AM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, Oct 14, 2014 at 5:07 AM, Marcos Chavarría Teijeiro chavarria1...@gmail.com wrote: Hi! I'm working on porting Yelp to WK2 as part of an Igalia internship [1] and in addition I'm creating a some kind of tutorial/cookbook to help people to port WK1 app to WK2. You cand find the tutorial (it's a work in progress) here [2]. I hope it can help... Fantastic, thanks. I've added a link to the wiki page. ___ desktop-devel-list mailing list 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 -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgplKXBA1UT1z.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Robert Schroll rschr...@gmail.com writes: On Tue, Oct 14, 2014 at 10:17 PM, Michael Catanzaro mcatanz...@gnome.org wrote: Anyway, Robert and I spent yesterday morning learning how to get a very simple example of UI process - web extension IPC working via D-Bus. (Well, mostly working: Robert discovered today that our example D-Bus signal is broken) The plan was for him to publish the code on GitHub soon. I've put the example up on Github: https://github.com/rschroll/webkitdom. The README could use some work explaining what's going on, but it's late and I'm tired. In short, the master branch shows how things used to work with the old API, and the javascript and extension branches show two ways to get things to work with the new API. The javascript method is a bit simpler, but may not scale (and requires javascript); the extension uses the web extension with IPC over DBus. This latter example isn't working with DOM events, as I can't figure out how to use WebKit.DOM.EventTarget.add_event_listener_with_closure() from Vala. Any help here appreciated. (Michael, though the code doesn't demonstrate it, signaling from the Server back into the UI process is working in this example, despite it not working in your example. Dunno why.) I haven't looked at the code, but make sure you don't use DBus sync API when communicating the UI and web processes. I'll try to clean up the explanations a bit. I appreciate any feedback and corrections y'all can give. Thanks, Robert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpcXWenrfM8A.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Robert Schroll rschr...@gmail.com writes: On Tue, Oct 14, 2014 at 10:17 PM, Michael Catanzaro mcatanz...@gnome.org wrote: Anyway, Robert and I spent yesterday morning learning how to get a very simple example of UI process - web extension IPC working via D-Bus. (Well, mostly working: Robert discovered today that our example D-Bus signal is broken) The plan was for him to publish the code on GitHub soon. I've put the example up on Github: https://github.com/rschroll/webkitdom. The README could use some work explaining what's going on, but it's late and I'm tired. In short, the master branch shows how things used to work with the old API, and the javascript and extension branches show two ways to get things to work with the new API. The javascript method is a bit simpler, but may not scale (and requires javascript); the extension uses the web extension with IPC over DBus. This latter example isn't working with DOM events, as I can't figure out how to use WebKit.DOM.EventTarget.add_event_listener_with_closure() from Vala. Any help here appreciated. I don't know much about bindings, but I added the _with_closure() variants to make the API introspectable, and I remember I tried it with python and it worked. See https://bugs.webkit.org/show_bug.cgi?id=77835 (Michael, though the code doesn't demonstrate it, signaling from the Server back into the UI process is working in this example, despite it not working in your example. Dunno why.) I'll try to clean up the explanations a bit. I appreciate any feedback and corrections y'all can give. Thanks, Robert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgphv1QWlWseI.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Robert Schroll rschr...@gmail.com writes: On Wed, Oct 15, 2014 at 1:00 PM, Carlos Garcia Campos carlo...@gnome.org wrote: I don't know much about bindings, but I added the _with_closure() variants to make the API introspectable, and I remember I tried it with python and it worked. See https://bugs.webkit.org/show_bug.cgi?id=77835 Maybe I'm looking in the wrong places (it's a long bug), but the examples I'm seeing seem to be using the WebKitGTK bindings, not the WebKit2GTK bindings. The DOM API is the same in WebKit1 and WebKit2. Evan Nemerson suggested, The bindings should be updated to make the closure argument use the correct delegate type. Not knowing what the correct delegate type is, I've sent a query to the WebKitGTK list to see if we can get this fixed. Looking through the VAPI file, I noticed that there are bindings for remove_event_listener(), remove_event_listener_with_closure(), and add_event_listener_with_closure(), but not for add_event_listener(). This last method was the method used in the previous API. If I add the definition from there back into the current VAPI, it works just fine. Was its removal intentional? I don't know, where's that VAPI file? Thanks, Robert -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpB7JvZ2dVtt.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Shaun McCance sha...@gnome.org writes: On Tue, 2014-10-14 at 21:17 -0500, Michael Catanzaro wrote: On Tue, 2014-10-14 at 14:44 -0400, Matthias Clasen wrote: On Tue, Oct 14, 2014 at 1:47 PM, Jim Nelson j...@yorba.org wrote: It would be great if the DOM was available via WebKitGTK and the local library did the IPC for us, but I've been told that that's not going to happen. The DOM is a huge API and I can't blame them for that. I do wish the separate process model was an optional run mode because, as I said, I don't see a lot of benefits moving to it for Geary. I think Geary is really the worst-case scenario here: a fairly large application that performs significant DOM manipulations in response to UI events, already written with the WebKit1 API. For apps that are just displaying web pages (everything not geary?) with no such compatibility concerns, porting should be relatively easy. Geary might be worst-case, but Yelp is non-trivial. It does some DOM manipulation, and the whole way it pushes content to WebKit has to be changed. Yelp is easy! :-) We don't actually need to change the way content is pushed to WebKit, I switched the code to use custom uri schemes for the schemes managed by yelp because I thought it was the right way instead of the the current approach of using fake uris. Carlos did a ton of patches on Yelp, more recently updated by Marcos, but I haven't had time to fully test them. A lot of corner cases could blow up when you change that bit of code. Right. Honestly, the WebKit1 API seemed on the whole nicer to work with for any application that isn't a web browser. What about Empathy? A chat display strikes me as something that's more about data insertions than showing some URI. The process separation is mostly transparent for most of the cases, unless you need to access the DOM. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpEX2VUGHEd3.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Webkit2 porting
Matthias Clasen matthias.cla...@gmail.com writes: Hi, one thing that was discussed a bit here at the Boston Summit is the situation with webkit - we are currently depending on both webkit1 and webkit2, which is not a good situation. Yes :-( Unfortunately, porting to webkit2 requires some work (in the case of geary, quite a bit of work). It's possible that in some cases we need to add new API to WebKit, for those cases, I encourage people to file reports bugs as soon as possible, so that we have the whole cycle to design, implement and test the new API additions. Also, feel free to add me to the CC of any bug containing patches that I could help reviewing or whatever. I've started to set up a page here to track this: https://wiki.gnome.org/Initiatives/GnomeGoals/Webkit2Porting It needs a lot more information - I'm not an expert on webkit, so any help in fleshing this out would be appreciated. Ok, I'll start by adding the status of modules I know about. Remember that we are always available to help in out mailing list webkit-...@lists.webkit.org and #webkigtk+ on freenode. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpEhptPHbav6.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu Help/About consistency
Rick Opper rickop...@gmail.com writes: ok... App Menu: * About (I guess optional now?)/Help... * Quit - At least this one seems to be consistent... * Preferences for the app Window/Document Menu: * File operations (new, open, save(as))... * Window/view preferences Should be simple, but... Nautilus has 4 buttons - 2 menus and 2 presets for views. Documents has NONE, just a magnifying glass and a check button... Evince has nothing in the app menu, and 2 impossibly unorganized window menus - I never know which one to open... Evince has help in the app menu, and it doesn't have About because the implementation is a modal dialog attached to a specific window. It has a view menu and a gear menu, and I agree it's not easy to know which options are in each menu. It's not even obvious that the view menu is shown by pressing on the button. Just to say that for us users - I'm not a developer - consistency is very comforting, and a sign of quality, and for developers, I don't think it's an issue of being spoon-fed, but rather having a clearer sense of direction. Nautilus, Documents, and Evince devs want to have good products and probably made their decisions for the best as they could see it. Having clearer instructions or a better idea of what the menu system should look like could help them decide where to put your super menu item and keep it consistent... I'm sure you have some idea of image in mind for what these menus should be like and having it fleshed out more - liked or not liked - can only help developers and the community either implement it or at least discuss it... OK, that's my 2 cents - I've been using gnome since 2.6... can't code to save my life though :-( On Mon, 2013-11-25 at 14:36 +, Allan Day wrote: Pierre-Yves Luyten p...@luyten.fr wrote: [1] https://wiki.gnome.org/Design/HIG/ApplicationMenus Could this document be extended to cover the switch between the different views? See https://bugzilla.gnome.org/show_bug.cgi?id=697591. One of the goals for the new HIG is to try and avoiding spoon-feeding people too much, and I'd prefer to avoid listing every possible thing you might want to include in that menu. In that sense, this bug is an interesting test case for the guidelines. In general I would say that they indicate that those items shouldn't be in the app menu, since they are specific to a particular window or view, but I'd be interested to hear how other people would interpret this based on the draft guidelines, and whether they consider them to be useful enough. Allan ___ desktop-devel-list mailing list 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 -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpNNerTvWn2n.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu Help/About consistency
Michael Catanzaro mcatanz...@gnome.org writes: On Mon, 2013-11-25 at 14:36 +, Allan Day wrote: In general I would say that they indicate that those items shouldn't be in the app menu, since they are specific to a particular window or view, but I'd be interested to hear how other people would interpret this based on the draft guidelines, and whether they consider them to be useful enough. Actions that are specific to a particular window or view, or which act on content within an application window, should not be included. The middle clause is somewhat stronger than previous guidelines, and I think it makes a difference. I interpret that to mean that even if your app is single-instance, you're unambiguously not supposed to put anything that affects the window in the app menu. That's a big step towards making app menus more consistent and minimalist, removing the present conceptual divide between app menus for single-instance and multi-window apps. This means Documents, Rhythmbox, and Calculator need to find a new home for their View settings, for example. It also means we need to be more aggressive in removing actions that affect the window: for instance, many games place Undo in the app menu, and Epiphany puts Reopen Closed Tab there, both of which would need to be moved. I'm also pleased that these guidelines unambiguously address apps like Terminal, which does not currently place Quit in the app menu, and Evince, which does not currently put either Quit or About there. One area that could be clarified is the precise behavior of Quit: should it close the focused window only or all windows of the application (a current inconsistency between some apps), or even all windows on the present workspace? It's easy to forget that you have Web open on workspace three, and accidentally close it in workspace one, which sucks; but if Quit doesn't affect all windows, it's not really a global setting. Exactly, and those are the reason why we don't have Quit at all in Evince. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpuNfaVAKeyx.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu Help/About consistency
Bastien Nocera had...@hadess.net writes: On Mon, 2013-11-25 at 08:49 -0600, Michael Catanzaro wrote: On Mon, 2013-11-25 at 14:51 +0100, Bastien Nocera wrote: FWIW, I think that core apps shouldn't have an about menu item at all, and it's what I've done in Totem^WVideos for example. Maybe. It's nice to be able to see the version number, though. The version number would be the same as the one in Settings - Details. It's not only the version number, but additional information, for example Epiphany shows the WebKit version, and Evince shows the document backend in use and its version as well. If more is needed for debugging, it should be part of what Oops offers: https://wiki.gnome.org/Design/Apps/Oops ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpkNWaXdALfi.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu Help/About consistency
Michael Catanzaro mcatanz...@gnome.org writes: On Mon, 2013-11-25 at 20:00 +0100, Carlos Garcia Campos wrote: It's not only the version number, but additional information, for example Epiphany shows the WebKit version, and Evince shows the document backend in use and its version as well. All of which are fairly important when working on bugs. gnome-abrt (or some future Oops) is not ready to handle this, will not work outside Fedora within the foreseeable future, and will not be included in many/most distributions ever. And not all bugs are crashes fortunately :-), the poppler or webkit version used by evince and ephy is quite important for rendering bugs, for example. And I cannot believe that we would refuse to make new releases of Totem, Documents, and Dictionary(!) except in coordination with gnome-desktop. Or that Ubuntu would enforce that coordination if we did. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpogNIhMQQqs.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu Help/About consistency
Bastien Nocera had...@hadess.net writes: On Mon, 2013-11-25 at 14:56 +0002, Yosef Or Boczko wrote: I disagree. We need a place with the names of the developers and the name of the app. The name of the app is already in the top bar, and the name of the developers for core apps is GNOME project. In that case we could keep the about dialog, for consistency with non-core applications, and to show other useful information (website, real app name, version, etc.) and use The GNOME project in the author field. I still think translators deserve credit, so I would leave the list of translators too. If the name of totem is 'Videos' in the UI, and someone want to visit in the web of totem, to repo bug or to contribute, he need the about dialog to know the right name is 'totem', so he know from where to start. Using the problem reporting application. Also, the about dialog is the place to five credit to the developers and to the translators (ans also to the designers). By that token, we should probably include everyone that works on every bit of technology that the application relies on. That's just not feasible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpdXogq498RV.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
Michael Catanzaro mike.catanz...@gmail.com writes: [...] 3) There's significant inconsistency in menu elements. Half place About above Help, half below. Half say About program name and half leave out the program name. Some new ones don't even have Quit -- I'm looking at GNOME Terminal and Evince here. Evince's in particular is a complete mess: it has ONLY Help, -- About in its gear menu instead, as is Close. The reason why About is not in the global menu is because the action is associated to a particular window, since it's a modal dialog attached to a window. That's not a global option in my opinion, even though I agree the concept of about dialog is indeed global because its contents is common for all windows. When you have multiple evince windows open (which is a common situation) selecting About in the global menu makes one of the windows (it might look even random when using focus follows mouse) shows the dialog attached to it. Help is different, because yelp is launched independently of the evince windows. So, we either leave the about in the window menu (it's a modal dialog of the window) or we make the about dialog actually global and not modal. I understand that in apps like Epiphany where you typically have a single or main window with multiple tabs, and usually maximized or large, having the about in the global menu and attached to the *main* window makes sense and looks good. But I don't think this is the case of Evince. I think Evince doesn't want to have a way of closing all windows at once, and maybe that's what's up with Terminal as well. Yes, that's the Evince case, I don't know about terminal, though. Perhaps apps with multiple windows should define Quit to close only related windows, instead of all of them. What's the related window? the last focused one? this is very confusing, just use the window menu for window related actions. Can we agree that Help/About/Quit should be required in the app menu? I disagree. I think consistency is very important, but not all apps are used the same way, so it's not easy to find a global solution. I think there are groups of apps, for example, the apps that only have a window, or have the concept of main window, apps that typically run maximized, apps with multiple windows independent to each other, etc. These groups of apps should be consistent, but we can't expect that Quit means the same in all apps, for example. Quit is the one thing that used to be guaranteed to be there, even for third-party apps, and I don't think users should ever have any question as to where it is. Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 pgpo_TYK1l8Z4.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility team to automatically receive bugmail on a11y bug reports
Excerpts from Piñeiro's message of jue ago 16 13:31:19 +0200 2012: On 08/10/2012 07:15 PM, Andre Klapper wrote: On Tue, 2012-07-31 at 12:28 +0200, Piñeiro wrote: Sorry Andre, I misunderstood you when we were talking about this at the GUADEC. I also misunderstood you (and maybe didn't make it clear). Sorry. And following the list of sorries, sorry for my late reply. Other idea: Bugzilla components can have an [optional] Default CC beside having the Default Assignee and Default QA Contact. In case we push for an Accessibility component in each product (Ekiga and Empathy already have that), a specific address that a11y can follow could be added to the Default CC list for each a11y component (like accessibility-t...@gnome.bugs). Would that address your needs? Yes, I think that this would address our needs. Being CCed to the accessibility bugs while the default assignee remains one of the module developers makes sense to me. Still I haven't seen any feedback from module maintainers in this thread, and whether an Accessibility component in Bugzilla would be accepted. Feedback welcome. Well, probably it is because it was a vague idea of some interesting modules, probably we could list them explicitly and see if someone catches the ping. Being minimalistic we can start with: * clutter (it already has cally, so we can use it or just rename it) * gtk+ (it already has gail, so we can use it or just rename it) * gnome-shell * gnome-control-center * gdm * empathy * gedit * nautilus * evince I have no objections to create an Accessibility component in bz for Evince. And several doubts with respect to evolution (my vote right now is no) BR -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome fallback panel applet creation problem
Excerpts from Syco's message of vie sep 16 09:26:53 +0200 2011:
I'm trying to create a panel applet, but I'm stuck at the first step:
I've created a file.cpp with the code from the official example at
http://developer.gnome.org/panel-applet/3.0/getting-started.example.html
|#include gtk/gtk.h
#include panel-applet.h
static gboolean hello_world_applet_start (PanelApplet *applet) {
GtkWidget *label;
label = gtk_label_new (Hello World);
gtk_container_add (GTK_CONTAINER (applet), label);
gtk_widget_show_all (GTK_WIDGET (applet));
return TRUE;
}
static gboolean hello_world_factory_callback (PanelApplet *applet, const
gchar *iid, gpointer data) {
gboolean retval = FALSE;
if (g_strcmp0 (iid, HelloWorldApplet) == 0)
retval = hello_world_applet_start (applet);
return retval;
}
PANEL_APPLET_OUT_PROCESS_FACTORY (HelloWorldFactory, PANEL_TYPE_APPLET,
hello_world_factory_callback, NULL)
|
compiled with
|g++ -Wall -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE `pkg-config --cflags --libs gtk+-3.0
libpanelapplet-4.0` *.cpp -o helloworld
|
and copied under
|/usr/lib/gnome-panel/helloworld|
then I've created the file
|/usr/share/gnome-panel/4.0/applets/helloworld.panel-applet|
with this content:
|[Applet Factory]
Id=HelloWorldFactory
InProcess=true
Location=/usr/lib/gnome-panel/helloworld
Name=Hello World Applet Factory
Description=Factory for the window navigation related applets
[HelloWorldApplet]
Name=Hello World
Description=Factory for the Hello World applet example
Icon=hello-world-icon
|
all the code is taken from the documentation, but when I try to add the
applet to the panel I had this error:
|** (gnome-panel:24803): WARNING **: Failed to load applet
HelloWorldFactory::HelloWorldApplet: /usr/lib/gnome-panel/helloworld: cannot
dynamically load executable|
what's wrong??
The problem is that you are creating an out of process applet, using
PANEL_APPLET_OUT_PROCESS_FACTORY, but defining it as in process in the
panel-applet file, InProcess=true. You can just remove both keys
InProcess and Location from the panel-applet file and use a dbus
service file to activate the applet.
Thanks.
Regards,
--
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462
signature.asc
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump poppler min version to 0.16
Hi, poppler 0.16 is the new stable release. The glib frontend api has changed, and as usual a lot of important bugs have been fixed. Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Olav Vitters's message of mar dic 28 22:18:19 +0100 2010: On Tue, Dec 28, 2010 at 05:53:35PM +0100, Carlos Garcia Campos wrote: Excerpts from Olav Vitters's message of mar dic 28 17:25:31 +0100 2010: Are you talking about the 3.0 version? I'd expect bonobo to be dropped for a 3.0 panel. I'm talking about gnome panel from git master, vuntz added support for bonobo applets to make the transition easier. Anyway, we need vuntz for the real answer. I'm not sure, but I think the idea was dropping bonobo support when most of applets are ported to dbus. Also for 2.x? For 3.0 I don't expect anything other than no bonobo, as bonobo is deprecated and we're dropping all deprecated stuff. There's no gnome-panel 3. My only wonder is regarding gnome-panel + applets being the fallback option.. so maybe somehow different rules apply. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Emmanuele Bassi's message of mar dic 28 23:47:29 +0100 2010: On Tue, 2010-12-28 at 23:07 +0100, Luca Ferretti wrote: Il giorno mar, 28/12/2010 alle 16.50 +, Emmanuele Bassi ha scritto: On Tue, 2010-12-28 at 13:42 +, Sergey Udaltsov wrote: Sergey, who sometimes prefers to look backwards rather than forward no problem with that. you can maintain the old user experience for yourself and never upgrade. and snarkyness is never going to get you anything, mmkay? (cit.) :P it wasn't at all meant to be snarky[0], nor was I sarcastic in any way, shape or form. it is, in fact, an exact assessment of what anyone who wishes to keep the old user experience should do: there's no need to ever upgrade if the 2.x UX is doing the job. My only concern is people who *can't* use gnome-shell because of hardware requirements, and it isn't a matter of buying a new computer, my previous laptop was a modern one, but the nvidia card made imposssible to use gnome-shell for more than 5 minutes. So, my point is, if we want to provide a fallback for those people and we are going to use gnome-panel and metacity because they are already there, why not keeping the applets too for the same reason? If I couldn't use gnome-shell, I would still want to upgrade all other modules to 3.0 and use a fallback mode without loosing the weather applet, for example. +++ by the way, this whole thread is pretty angry and confrontational - or, at least, it feels a lot that way. the 3.x UX is not complete, and will probably take some development cycles to iterate over the various ideas that are being experimented; I think it's been implied many times, since we all know that the 2.x UX took years to reach the point where we had to chuck a lot of it away to make room for something that was designed from the ground up, instead of the result of convergent bumping around of ideas. I don't think anyone in the Shell team or in the gnome-design team has stopped taking into consideration new ideas - though, obviously, they have to balance that with the resources being what they are. this whole thread, like the *many* others that preceded it, has been fairly aggressive in the pushback of the new design - it doesn't implement that pet feature, it requires hardware capabilities that not every one is willing to commit to, etc. - and while on one side my initial reaction was to say: well, tough - here's a nickel kid, go buy yourself a better computer; and if you want to keep using gnome2 feel free to maintain the pieces you require; and if you don't want to, then there's the door: don't let the it kick you in the ass too hard on your way out; but that was just my initial reaction, and I'm *really* trying (and willing) to tune that down. might be that the old age is finally catching up on me. I understand the pushback to changes. I understand that something that was designed from the ground up is still missing some feature. I understand that that design calls for some drastic changes in how the user experience should be shaped, which means that some features will not be implemented. these are choices made by people that generally know what they are doing, and that have been trusted for years by the whole community of people that show up in GNOME. I'm pretty sure they haven't been replaced by pod people. I guess the same measure of trust should be still applied, even if we don't immediately see the endgame. if that measure of trust cannot, or will not, be applied then we can give up creating a coherent Operating System, and we can go back maintaining separate pieces of an OS, with small time collaboration between projects, and design deferred to drive-by ad horizontal patching done by heroes trying to drain the swamp. ciao, Emmanuele. [0] unlike the time when I replied to you with the phrase you quoted. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Rui Tiago Cação Matos's message of mar dic 28 14:02:55 +0100 2010: On 28 December 2010 12:53, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I think the fact that GNOME kills gnome-applets make GNOME2 compatibility mode a bad joke (if not hypocrisy). A good number of people would like to use that mode (I run voting some while ago at linux.org.ru - can provide url if someone interested) - and GNOME is going to provide them with just crooks, not a real solution. I am sure one of the most important reasons people choose GNOME2 compatibility mode is the applets (I guess noone thinks that gnome-panel itself is so attractive that people cannot live without it). To be honest, not them, us - because personally I am going to stay in that mode as long as possible, so I really would like to have it working. What you want is not Gnome 3 then. You want to continue using Gnome 2 and there's no one preventing you from doing that. I don't think gnome 3 is just gnome-shell. There a lot of more changes in other modules, specially in the platform, that make the upgrade worth it. Rui -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Josselin Mouette's message of mar dic 28 15:03:45 +0100 2010: Le mardi 28 décembre 2010 à 13:02 +, Rui Tiago Cação Matos a écrit : What you want is not Gnome 3 then. You want to continue using Gnome 2 and there's no one preventing you from doing that. Is the GNOME 3 panel compatible with the GNOME 2 applets? There's no gnome 3 panel, gnome-panel hasn't been ported to gtk3 yet, there's a branch but it's outdated and it still doesn't work. If so, that’s fine. We distributors can keep on shipping gnome-applets as we do today, with the 2.32 version. If not, you’ve effectively just killed the panel. There’s no way we can maintain two versions of the panel, requiring two versions of g-c-c, themselves requiring two versions of g-s-d. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Olav Vitters's message of mar dic 28 15:20:05 +0100 2010: On Tue, Dec 28, 2010 at 03:03:45PM +0100, Josselin Mouette wrote: Le mardi 28 décembre 2010 à 13:02 +, Rui Tiago Cação Matos a écrit : What you want is not Gnome 3 then. You want to continue using Gnome 2 and there's no one preventing you from doing that. Is the GNOME 3 panel compatible with the GNOME 2 applets? Only with dbus applets, AFAIK (and hope). gnome-panel currently supports both dbus and bonobo applets. IIRC some work is needed on gnome-applets to port them properly to latest gtk+ (and so on). If someone bothers (I'm guessing between GNOME 3.0 and 3.2), I don't see any reason not to release a new tarball with those changes. Whether or not that is supported doesn't really matter. However, the fallback is meant as a fallback, not as providing gnome-panel and its applets. So I don't see anything wrong with not providing the applets. While at the same time, I don't see anything wrong with releasing a new gnome-applets tarball. Meaning: GNOME 3 is not gnome-panel and never will be. But if someone still hacks on gnome-applets nobody will work against them. I do hope at one point we won't need the gnome-panel fallback (quick enough software rendering or some other experience). That said, think it would be good to provide a gnome-applets which works with gtk+ 3.0. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
Excerpts from Olav Vitters's message of mar dic 28 17:25:31 +0100 2010: On Tue, Dec 28, 2010 at 04:54:43PM +0100, Carlos Garcia Campos wrote: Excerpts from Olav Vitters's message of mar dic 28 15:20:05 +0100 2010: On Tue, Dec 28, 2010 at 03:03:45PM +0100, Josselin Mouette wrote: Le mardi 28 décembre 2010 à 13:02 +, Rui Tiago Cação Matos a écrit : What you want is not Gnome 3 then. You want to continue using Gnome 2 and there's no one preventing you from doing that. Is the GNOME 3 panel compatible with the GNOME 2 applets? Only with dbus applets, AFAIK (and hope). gnome-panel currently supports both dbus and bonobo applets. Are you talking about the 3.0 version? I'd expect bonobo to be dropped for a 3.0 panel. I'm talking about gnome panel from git master, vuntz added support for bonobo applets to make the transition easier. Anyway, we need vuntz for the real answer. I'm not sure, but I think the idea was dropping bonobo support when most of applets are ported to dbus. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Excerpts from William Jon McCann's message of vie dic 24 00:32:40 +0100 2010: Hi Carlos, Hi, On Thu, Dec 23, 2010 at 1:54 PM, Carlos Garcia Campos carlo...@gnome.org wrote: Excerpts from Frederic Peters's message of jue dic 23 10:22:40 +0100 2010: Hi, Sergey Udaltsov wrote: I am confused, what's the story with gnome-panel and gnome-applets in 3.0? Are they in, are they out? If gnome 3 is to support gnome2 compat mode, both of these components should stay in for some while, right? Currently, the situation in in jhbuild is very strange: gnome-panel is still there, gnome-applets are gone. Is this planned? Who'd need the panel without the applets? I pointed this after the new modulesets were pushed, you can read the answer Jon gave here: http://mail.gnome.org/archives/release-team/2010-December/msg4.html The relevant part: | - gnome-applets (even if we still have gnome-panel) | | RIP. Essential applets should be part of gnome-panel itself. It | doesn't make sense to have applets only in the gnome 2 fallback | experience. 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. GNOME 2 fallback experience should be gnome-panel, metacity and gnome-applets. It is important to note that there is no such classic mode. There is a fallback mode for when 3D support is not available. Then this is confusing: http://git.gnome.org/browse/gnome-session/tree/data/classic-gnome.session.desktop.in.in note that to run the fallback you need something like $ gnome-session --session classic-gnome so I would suggest to rename it to fallback or whatever to avoid confusions, since what I expect from a classic session is what we have been using for years. The fact that it will use some of the GNOME 2 components is mostly an implementation detail - it is way more efficient than building something else. (That said, I think someone could hack up a simple panel + system status equivalent in javascript in no more than a few weeks if they wanted to. And I think that would actually be preferable for a number of reasons.) There is no I want a new GNOME but not GNOME 3 mode. There aren't two GNOMEs - only the one we barely have enough help designing, building, and testing already. If you want your system to be exactly as it is now my recommendation would be to leave it just as it is now. It's not a problem of what users want, many people want gnome 3 but they can't run the shell because of the 3D support. What I meant was that if I can't run gnome-shell (even if I wanted) I expect the fallback mode to be what I had in gnome 2, because otherwhise gnome 3 will be a regression for non 3D users. It doesn't make any sense for the user to have an entirely different concept in the fallback that isn't available in the default. Nor does it make any sense for us to provide a developer API and add-on system that only works in the fallback mode. gnome-panel is already an entirely different concept, that's why I don't see the problem of leaving the applets too. GNOME 3 is a change. Both the default and the fallback modes will be different from GNOME 2. We can't and shouldn't shy away from that. I don't know if there are plans to work on gnome-panel for gnome 3, but in this moment the panel is exactly the same, or even worse since it doesn't even work with gtk3. People who don't desire such changes are not obligated to make them. I agree, note that I'm thinking of people who can't use the shell (and fortunately I'm not one of those anymore, since I bought a new laptop recently and I took care of buying it with an intel video card to make sure I'll be able to use gnome3 with gnome-shell) Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Excerpts from Frederic Peters's message of jue dic 23 10:22:40 +0100 2010: Hi, Sergey Udaltsov wrote: I am confused, what's the story with gnome-panel and gnome-applets in 3.0? Are they in, are they out? If gnome 3 is to support gnome2 compat mode, both of these components should stay in for some while, right? Currently, the situation in in jhbuild is very strange: gnome-panel is still there, gnome-applets are gone. Is this planned? Who'd need the panel without the applets? I pointed this after the new modulesets were pushed, you can read the answer Jon gave here: http://mail.gnome.org/archives/release-team/2010-December/msg4.html The relevant part: | - gnome-applets (even if we still have gnome-panel) | | RIP. Essential applets should be part of gnome-panel itself. It | doesn't make sense to have applets only in the gnome 2 fallback | experience. 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. GNOME 2 fallback experience should be gnome-panel, metacity and gnome-applets. Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump poppler min version to 0.14
Poppler 0.14 is the new stable release, in Evince we have code that depends on new api (checking availability in configure). Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
El mié, 16-09-2009 a las 01:58 +0200, Andre Klapper escribió: On Thu, 2009-09-10 at 11:06 +0200, Carlos Garcia Campos wrote: Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? So is 0.12 the stable version of 0.11? yes Am Donnerstag, den 10.09.2009, 13:20 +0200 schrieb Maciej Piechotka: Isn't this version of poppler breaking some packages from texlive? Any bug report ID? andre -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hard code freeze break request for gvfs
Bug 595356 - query_writable_namespaces() doesn't return metadata even though it's supported In order to know whether metadata is supported for a given file we call g_file_query_writable_namespaces() so that if metadata is in the list of writable namespaces we can safely get/set metadata on that file. That doesn't work for non local files in this moment due to bug #595356. Attached to the bug there's a trivial patch that has been already approved by alex. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince branched for 2.28
I've just branched for GNOME 2.28. Development for 2.30 will continue on master. gnome-2-28 is the new stable branch. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
El dom, 13-09-2009 a las 14:05 +0200, Vincent Untz escribió: Le jeudi 10 septembre 2009, à 11:06 +0200, Carlos Garcia Campos a écrit : Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? My understanding is that we already require 0.11, and that 0.12 is the stable version of 0.11. Is that right? right, I didn't remember we already required 0.11. If yes, then +1. Vincent -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
El jue, 10-09-2009 a las 13:20 +0200, Maciej Piechotka escribió: On Thu, 2009-09-10 at 11:06 +0200, Carlos Garcia Campos wrote: Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? Isn't this version of poppler breaking some packages from texlive? Is it fixed? I don't know anything about any breakage in texlive. When a new poppler version breaks another program is usually because such a program is using the internal poppler API (which is strongly discouraged). In that case it's the other application what needs to be fixed. In such case it would make Gnome adoption in distributions longer. Regards -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
El jue, 10-09-2009 a las 16:56 -0300, Gustavo Noronha Silva escribió: On Thu, 2009-09-10 at 11:06 +0200, Carlos Garcia Campos wrote: Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... I don't see much point in requiring a newer version for performance reasons. well, it's not only because of performance reasons, I also said there are important rendering issues fixed in this release. Performance issues are usually not so important when the improvement has a low impact, but in this case we are talking about several minutes to render just one page to less than a second (see bug in [1]). This doesn't really help people who are usually tracking newer versions, and causes trouble to people who are trying to backport newer versions of specific applications to older distributions. You can always add comments to README or whatever suggesting an upgrade, though =) This usually doesn't work, often distros don't package new versions until they are required by any other package. When that happens, users of such distros don't test the new version and report the same bugs that were already fixed. See you, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
El vie, 11-09-2009 a las 09:36 +0200, Carlos Garcia Campos escribió: El jue, 10-09-2009 a las 16:56 -0300, Gustavo Noronha Silva escribió: On Thu, 2009-09-10 at 11:06 +0200, Carlos Garcia Campos wrote: Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... I don't see much point in requiring a newer version for performance reasons. well, it's not only because of performance reasons, I also said there are important rendering issues fixed in this release. Performance issues are usually not so important when the improvement has a low impact, but in this case we are talking about several minutes to render just one page to less than a second (see bug in [1]). forgot the url :-P http://bugs.freedesktop.org/show_bug.cgi?id=13518 -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump minimum version of poppler to 0.12.0
Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump minimum version of poppler to 0.11.0
Poppler 0.11.0 has just been released. It's the first unstable release leading up to 0.12. It includes the new API needed to add support for annotations in Evince. Any objection? Thanks, -- Carlos Garcia Campos elkalm...@yahoo.es carlo...@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
El dom, 02-11-2008 a las 17:02 -0600, Jason D. Clinton escribió: 2008/11/1 Philippe Rouquier [EMAIL PROTECTED] Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1, a wonderful application. n-c-b should be completely removed. Well, I love brasero and I'd like to see it in GNOME but I also agree with Bastien that the simplicity of the workflow provided by N-C-B is very important and probably many users are already used to it. So, I think the nautilus integration should be kept, it doesn't matter whether it's implemented by N-C-B or brasero though. -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince branched for 2.24
Evince has just been branched for 2.24. New development will continue on trunk. -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump poppler external dependency to 0.8.0
Poppler 0.8.0 is the current stable release. Many bugs have been fixed, annotations support has been included and the glib API has changed. Enough? :-P -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince branched for 2.22
Evince has been branched for 2.22. The main goal for this cycle is finally adding annotations support. More info in the Roadmap (http://live.gnome.org/RoadMap/Evince) -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump poppler external dependency to 0.8.0
El mié, 09-04-2008 a las 19:20 +0200, Vincent Untz escribió: Le mercredi 09 avril 2008, à 19:18 +0200, Carlos Garcia Campos a écrit : Poppler 0.8.0 is the current stable release. Many bugs have been fixed, annotations support has been included and the glib API has changed. Enough? :-P For 2.22 or 2.23? hmm, I think we can bump recommended to 0.8 for 2.22 and both minimum and recommended for 2.23 Vincent -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump poppler external dependency to 0.8.0
El mié, 09-04-2008 a las 19:35 +0200, Vincent Untz escribió: Le mercredi 09 avril 2008, à 19:29 +0200, Carlos Garcia Campos a écrit : El mié, 09-04-2008 a las 19:20 +0200, Vincent Untz escribió: Le mercredi 09 avril 2008, à 19:18 +0200, Carlos Garcia Campos a écrit : Poppler 0.8.0 is the current stable release. Many bugs have been fixed, annotations support has been included and the glib API has changed. Enough? :-P For 2.22 or 2.23? hmm, I think we can bump recommended to 0.8 for 2.22 and both minimum and recommended for 2.23 Sounds good. Can you make the change in gnome-external-deps-2.24.modules? Sure, done. Vincent -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSOC 2008 advice
El mar, 26-02-2008 a las 15:18 -0600, Benjamin Gramlich escribió: Thank you to everyone who has responded so far. Spending a summer hacking Gnome is going to be splendid. About 4 months ago (I think it was October), there was a discussion here about the panel. I was directed to desrt's work, but it doesn't seem to be complete. I think a rethink of the panel would be a great idea. Both John and Luis brought up the idea of widgets/gadgets/gidgets. This is definitely an idea that Gnome should implement. Personally, I think it would be neat to develop an interface for gadgets so that they could be deployed to the desktop as gadgets, but then dragged to the panel to function as applets. I also think that the current iteration of the panel is a little stale. While there doesn't seem to be any agreement as to how to design a new panel, I feel we should try to move in that direction. AWN is designed well, but it requires a composited environment. This is problematic for people with older PCs and everyone with an ATI card :). I propose a hybrid between the traditional panel and a dock. The menu should also be modernized. Vista's menu has a fixed size by default, and thus requires a scrolled window once the menu becomes to large (this is bad), but it has two panes (one for the program menu and one with shortcuts to file locations) and a search box (these are good!). The gnome menu would benefit from these two additions. (It could also look prettier, like openSUSE's menu). I know I'm all over the place here, I'm just trying to brain storm and start a discussion. The last discussion about the panel fizzled out some time ago. I know that Vincent wants to completely remove the bonobo dependency from the panel/applet-library, but on the roadmap he also mentioned a compatibility layer for old bonobo based applets. If the gnome default applets were re-written could we proceed with an API break in order to implement something new? I think all the new ideas about the panel and the applets are quite nice, however implement them would take a long time. If we want to remove the bonobo dependency from the panel for now, we can just port the current libpanel-applet to D-Bus which can be easily done in a release cycle. Since most of the changes would be in the library and not in the applets I don't think it's worth to keep bonobo compatibility. Porting applets should be a really easy task that could be done as a GNOME Goal. Looking forward to it, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince hard code freeze break request
Hi all, evince 2.19.92 was released depending on poppler 0.6, so I removed a lot of #ifdefs for the features that were already implemented in evince but not yet in a poppler release. The thing is that I removed from the configure the HAVE_FORMS macro but I forgot to remove one of the #ifdefs in the code. In summary, evince 2.19.92 doesn't support interactive forms :-P So, here is the trivial path to fix it: http://carlosgc.linups.org/files/ev-forms-macro.diff Ok to commit? -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
External deps: update poppler
Hi, poppler 0.6 has just been finally released. We would like to release evince today depending on it. Poppler glib API has changed again, so we need to update not only the minimum, but the required version. Is it feasible? Thanks, -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
External deps: update poppler
Hi, poppler has just released 0.5.9 version. This version has changed the API in the glib bindings and a lot of important bugs have been fixed. Evince now depends on this new version, so I suggest to update both the minimum and required version of poppler to 0.5.9 for GNOME 2.20. -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME subversion migration
El mar, 26-12-2006 a las 22:12 +0100, Kjartan Maraas escribió: tir, 26.12.2006 kl. 17.24 +0100, skrev Mikael Hallendal: 18 dec 2006 kl. 13.35 skrev Ross Golder: Hi Ross, Is there a way to submit modules that you don't want in the move? I have a module called 'loudmouth' that I will move to git as the old CVS repository renders obsolete. Maybe we should consider setting up a formal git infrastructure so that projects that want to use git will have a way to distribute their repositories in a more standard way across GNOME? I'm only worried about one thing, is it possible to migrate from CVS to git (or any other distributed system) without losing the history? git.gnome.org anyone? With a gitweb interface? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel and libpanel-applet port to dbus
El sáb, 07-01-2006 a las 20:20 +0100, Chipzz escribió: On Sat, 7 Jan 2006, Vincent Untz wrote: + I think this means that we won't have in-process applets anymore. We're not using them right now, but some people wanted to use them for performance reasons. It's okay for me, though :-) This would be really bad, as I think the plan was (for at least the clock applet) to make them in-process, which I'm totally pro. Of course, we are not going to remove them, I forgot to mention it in my first mail. I haven't implemented it yet because I think it has less priority at the moment since we are not using them right now. kr, Chipzz AKA Jan Van Buggenhout -- Carlos Garcia Campos (KaL) [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
evince string freeze breackage
My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 I wanted to commit ASAP because of the evince release and I forgot that it changed some strings. sorry. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 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: evince string freeze breackage
El mié, 17-08-2005 a las 19:23 +0200, Danilo Šegan escribió: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document if we can't convert a filename to a utf-8 string, we prefer not to show that filename. actually necessary and important at this stage of the game? maybe not, but I guess evince maintainers should answer it. They are used only if g_locale_to_utf8 fails to convert filename to UTF-8 for display purposes, right? (you can reuse the same string with something like g_strdup_printf(_(Cannot open file: %s\n), ?) until string freeze ends.) yes Can you please revert these string additions or please provide more evidence to why is this really beneficial. Thanks. I wanted to commit ASAP because of the evince release and I forgot that it changed some strings. sorry. Regarding recent when freeze actually begins[1] thread, are you saying that this is about a release done for the Beta2? Beta2 was already announced on August 11th, and the patch was committed only on August 16th. oh no, I meant new evince release to fix building problems: http://bugzilla.gnome.org/show_bug.cgi?id=309915#c10 [1]http://mail.gnome.org/archives/gnome-i18n/2005-August/msg00160.html Cheers, Danilo -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 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: evince string freeze breackage
El mié, 17-08-2005 a las 14:34 -0400, Matthias Clasen escribió: On Wed, 2005-08-17 at 19:40 +0200, Carlos Garcia Campos wrote: El mié, 17-08-2005 a las 19:23 +0200, Danilo Šegan escribió: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document if we can't convert a filename to a utf-8 string, we prefer not to show that filename. Glib has g_filename_display_name() for the purpose of converting filenames into something that can be displayed to the user. It tries to handle conversion failures gracefully. I've just fixed it by using g_filename_display_name, thank you. Sorry for the problems caused, I'll be more careful in the future Matthias Greetings, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 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
