Re: SVG rendering - Librsvg and Lasem
Hi, Le mer. 13 juil. 2016 à 13:27, Sébastien Wilmet a écrit : On Tue, Jun 21, 2016 at 03:41:48PM +0200, Emmanuel Pacaud wrote: This is a message I intended to write for some times, but the Toronto hackfest notes gives me incentives to actually send it. In these notes, there is a paragraph saying Benjamin seems not too happy with librsvg. So I would appreciate any feedback regarding lasem design and implementation, or any comment about the possibility of using lasem as a replacement of librsvg. Did you receive any feedback? Because there is no replies to this thread, but it looks to me an important subject if the GTK+ project is looking at using an SVG rasterizer library. No feedback, except for a request from Jakub to use lasem for icon theme rendering (which has motivated me to try to improve object extent measurement in lasem). Cheers, Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
SVG rendering - Librsvg and Lasem
Hi, This is a message I intended to write for some times, but the Toronto hackfest notes gives me incentives to actually send it. In these notes, there is a paragraph saying Benjamin seems not too happy with librsvg. And in fact, there is this library, Lasem, I have started to work on some years ago, that could be considered as a librsvg replacement: https://wiki.gnome.org/Projects/Lasem https://git.gnome.org/browse/lasem/ Good things about lasem: - It is based on gobjects - It has a DOM like API - It has a quite extensive support of the SVG 1.1 specification, similar to librsvg - It is as fast, if not faster, than librsvg - It uses less memory than librsvg - It has introspection support - It has gtk-doc support - There is a test suite, with an automatic check on a selection of test files - As a bonus, it also renders MathML (well, it started as a mathml renderer under gmathml name) Bad things about lasem: - Text support is a joke, but librsvg does not shine here neither - No CSS suport - Almost nobody uses it - There is only one developper, and not very active these days (that's me) - twice the size of code compared to lirsvg (but it has mathml rendering...) So I would appreciate any feedback regarding lasem design and implementation, or any comment about the possibility of using lasem as a replacement of librsvg. Cheers, Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libRSVG development
Hi, Le mardi 02 avril 2013 à 21:04 +0200, Andre Klapper a écrit : > Many projects are neither extremely active nor completely unmaintained. > (In case of librsvg, maintainers did some hacking seven months ago.) > > It might be worth to contact maintainers explicitly (see > https://git.gnome.org/browse/librsvg/tree/librsvg.doap ) and kindly ask > for review of specific patches (overview of unreviewed patches at > https://bugzilla.gnome.org/browse.cgi?product=librsvg ), or to issue a > call for new blood (or invite active patch writers to co-maintainership) > if there is no interest in maintainership anymore. > > I'm not aware of any alternative recommended within GNOME currently. I can't say it is much more active or maintained, but I would suggest to look at lasem, a library I'm working on for several years now. Compared to librsvg, support for filters is a bit behind, there's no CSS styling capability, and text rendering is even worse than librsvg. But it has a DOM like API, is quite fast, and has a large test suite. Plus it also can render mathml equations. More informations here: https://blogs.gnome.org/emmanuel/category/lasem/ https://git.gnome.org/browse/lasem/ Cheers, Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: taking features away (compact view removed from Nautilus)
Le lundi 02 juillet 2012 à 09:38 +0100, Allan Day a écrit : > Adam Dingle wrote: > > I realized recently to my surprise and dismay that the compact view has been > > removed from Nautilus: > > Adam, if you wanted to discuss this change, you could have done so on > the bug or on the Nautilus mailing list, or by asking on > #gnome-design. I would have been happy to have given you some > background on why the decision was made. Adam already answered to this point: "I'm well aware of nautilus-list, but chose to post here because I think there's a problem here beyond just Nautilus. In my opinion, useful features are vanishing from core GNOME apps without adequate notice to the community and opportunity for discussion by people who use those features regularly." > No one objects when you add a feature, yet features can ruin a design > if you keep adding them. Nautilus has been at saturation point for a > while; it's at the stage where it's actually very difficult to improve > it without taking something away. I don't use the compact view, but what worries me is, after several messages on this list, there is still no justification for this removal, except the one in the bug report: "There is really little difference between compact mode and icon mode with labels on the side. Well, except for that that horrible horizontal scrolling." That's a bit too short for an explanation (with the fact that the icon mode with labels on the side is also removed). While I agree removal are sometimes necessary, there is a good chance it will be seen as a regression by some users, which should be well explained. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
Le jeudi 03 mai 2012 à 16:56 +0200, Florian Müllner a écrit : > That messed up my hands and I can't use mouse. > That is why I liked gnome 2, everything could be done > without mouse. > > And the same is true for Gnome3 - to navigate to an application, you > can use > PgDown( | | ) Wouldn't it be better to make replace the PgDown sequence. When you enter the overview mode, arrow keys are not used, and it seems more obvious to use them in order to switch between "Window" and "Application" view. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone using UNCONFIRMED in Bugzilla?
Le mardi 27 décembre 2011 à 15:57 +0100, Olav Vitters a écrit : > On Tue, Dec 27, 2011 at 04:48:20PM +0200, pec...@gmail.com wrote: > > So please don't kill it. It's useful. > > Are you using it yes or no? I do, for the same reasons Peter described in his message. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Menus restructuring
Hi, Le mercredi 29 juillet 2009 à 12:35 +0200, Rodrigo Moya a écrit : > If the control center capplets provide a list of keywords in > their .desktop file, searching for 'mouse cursor' on the control center > shell search would show the correct tool that the user needs to start. But gnome-control-center shell is not there yet, and that's probably why some users don't like it: the current search keyword list is too poor to be useful. Say I want to set the double click delay for the mouse, the search feature doesn't give you a single answer, for either 'click' 'delay' or 'double', or even 'delay mouse', while it shows the correct applet for 'mouse'. And even if the keyword dictionary was big enough, an additional issue is the user needs to know how to name what he is looking for, which is not always that evident. Also, after a while, when you know where to find things, the one depth level menu layout is easier to memorize, at least for me, than the 2D layout of the gnome-control-center shell (which for making things worst, change when you resize the window). And as Alexey said, gnome-control-center shell is an additional window to close when you're done with your task. IMHO, a good compromise for the current gnome desktop would be to keep the system menu with the new layout proposal, and provide an access to the gnome-control-center applet using the search tool (tracker-search-tool or deskbar). We need a unique search tool, always at hand, and not several ones. We should not have to search for the correct search tool. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.26
Le jeudi 22 janvier 2009 à 11:42 +0100, Frederic Peters a écrit : > > Le mercredi 21 janvier 2009 à 19:20 +0100, Vincent Untz a écrit : > > > + brasero (desktop) > > >- mixed feelings in the community and in the release team > > >- reactive development team > > >- directly conflicts with nautilus-cd-burner feature-wise, so if > > > accepted, nautilus-cd-burner has to be deprecated > > >- fills a need that has been felt by many users > > >- used by default on several distributions already > > >=> approved > > >=> nautilus-cd-burner is therefore deprecated > > > > I'm not sure to understand what exactly happens here. Does brasero > > offers the same desktop integration for the basic cd burning needs as > > nautilus-cd-burner (right-click for iso burning, file to burn list > > building using nautilus windows, nice and simple burning dialog, > > shortcut to nautlus cd creation window on the desktop when a blank cd is > > inserted) ? > > As integration was a concern raised when Brasero was first proposed > they have working great to address the issues and added a Nautilus > extension, just like nautilus-cd-burner (actually it is much of the > same code), so integration features are not removed in favour of a > standalone application. Oh, good news then. Thanks. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.26
Hi, Le mercredi 21 janvier 2009 à 19:20 +0100, Vincent Untz a écrit : > + brasero (desktop) >- mixed feelings in the community and in the release team >- reactive development team >- directly conflicts with nautilus-cd-burner feature-wise, so if > accepted, nautilus-cd-burner has to be deprecated >- fills a need that has been felt by many users >- used by default on several distributions already >=> approved >=> nautilus-cd-burner is therefore deprecated I'm not sure to understand what exactly happens here. Does brasero offers the same desktop integration for the basic cd burning needs as nautilus-cd-burner (right-click for iso burning, file to burn list building using nautilus windows, nice and simple burning dialog, shortcut to nautlus cd creation window on the desktop when a blank cd is inserted) ? Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSD should not housekeep the thumbnails
Hi, On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote: > Hey guys, > The plugin does something like this: > - clean the thumbnails older than MAX_AGE (default to 60 days) > - clean the oldest thumbnails until the cache size is under MAX_SIZE > (default to 64MB) I don't get why it work like this. Why remove a thumbnail because it's old ? Why would we want to limit the size of the thumbnail cache to an arbitrary value ? It depends on the disk size, and it will limit itself by the fact the size of the thumbnailed files is largely bigger than the thumbnail size. Wouldn't it be better to just remove thumbnail of files that don't exist anymore ? Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Control Centre
Le lundi 05 février 2007 à 20:42 +0100, David Nielsen a écrit : > man, 05 02 2007 kl. 19:19 +, skrev Alex Jones: > > It's slow. > > > > Now when I want to quickly get to my sound settings I have to click > > System, Control Centre... *wait 3 seconds*, figure out where "Sound" > > should be and then click that. And then I have an extra window to close > > when I'm done, which really does annoy me. > > > > IMO this was just a proper bad idea. If we had a proper control centre > > app like Mac OS's then it would be a different story, but this thing is > > just a glorified application launcher that introduces an unnecessary > > layer of separation. > > > > Down with control centre. > > > > I want my menus back. Changing settings just isn't the quick > > in-and-out-in-5-seconds-flat job it used to be. > > I agree 100%, I like the idea but the current implementation is > extremely slow and it seems pointless since it just launches yet another > app. > Same feeling for me, and there's even a bug opened regarding this subject: http://bugzilla.gnome.org/show_bug.cgi?id=398970 Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: integrating python applications in the gnome desktop
Le dimanche 15 octobre 2006 à 14:44 +0100, Gustavo J. A. M. Carneiro a écrit : > On Dom, 2006-10-15 at 12:32 +0200, Alfonso wrote: > > I hope this is the right place for this question, sorry if it is not. I > > have googled quite a lot, and couldn't find any tutorial or information > > related with how can I install my python programms in the gnome desktop. > > I'm making programs using python and pygkt. What I would like to do is > > installing them, so that they can be executed just like any other > > application in the applications menu. If I try to execute a python > > program by double click in gnome it appears the dialog asking if I you > > want to show the content of the file or executing it. I know this > > behaviour can be changed using gconf-editor, but I would prefer not to > > change it, and still having my application integrated in the > > applications menu, and executable by double click without intermediate > > messages. > > Make a .desktop file for your program; it is double-click executable > without the annoying dialog. Plus, you can install it > to /usr/share/applications to make it visible in the GNOME menu. > > > > > Any information or links to articles or docs, would be very appreciated. > > http://freedesktop.org/wiki/Standards_2fdesktop_2dentry_2dspec There's also this guide: http://primates.ximian.com/~federico/docs/gnome-isv-guide/index.html Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PDFs for user-guide, accessibility-guide and system-admin-guide
Le mercredi 08 mars 2006 à 09:13 +0100, Alexander Larsson a écrit : > On Tue, 2006-03-07 at 22:57 -0700, Brent Smith wrote: > > I've been working on generating some new PDFs for the documentation in > > the gnome-user-docs package. I've come up with some build scripts[1] > > that generate some decent output using Apache's FOP and Norman Walsh's > > DocBook -> XSL-FO stylesheets. > > > > The generated PDFs are available at: > > > > http://www.gnome.org/~bmsmith/user-guide.pdf > > http://www.gnome.org/~bmsmith/system-admin-guide.pdf > > http://www.gnome.org/~bmsmith/gnome-access-guide.pdf > > Wow. These are pretty nice. Is there a chance we could pehaps make yelp > display this instead of the html-based versions? Evince manages to > render it with a nice index-tree sidebar and everything, so it seems > equivalent feature-wise. I don't think PDF is well suited for on screen reading. Font rendering and glyph spacing make document harder to read than when it's in html. Other points against PDF is that HTML rendering is faster, and page layout of PDF files leaves a lot of unused space (page borders, space between pages) with no gain regarding readability. Emmanuel. > Apple uses pdfs in their help systems (although not for everything i > think), and it looks pretty nice. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander LarssonRed Hat, Inc >[EMAIL PROTECTED][EMAIL PROTECTED] > He's an unconventional white trash astronaut gone bad. She's a foxy Bolivian > Valkyrie in the wrong place at the wrong time. They fight crime! > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
Le jeudi 01 décembre 2005 à 12:18 +0100, Alexander Larsson a écrit : > I would personally prefer a quick image viewer to not support editing > (and thus save, except "save a copy"), and implement rotation as a view > function, with auto-rotation bases on the file metadata. > It could even > reuse the rotation you used last time (saved on a per-file basis). Instead of saving rotation in a separate file, why not change metadata of the file itself ? Possibly with a preference titled "Automatically update file rotation metadata". If checked and file is read/write, save in file metadata, if not, save rotation setting in a separate file. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
