- Inkscape Devel - Inkscape Mailman

[Desktop_architects] Portland: The Linux Desktop Integration Interface
by Bryce Harrington 06 Dec '05

06 Dec '05

One of the things that's come out of the desktop architect's meeting was the need for something to simplify having to choose between GNOME and KDE. This need has spawned a new project called "The Portland Project", formed by leaders from KDE and GNOME (and a bunch of other projects). Briefly stated, the goal of the Portland Project is to make KDE and GNOME work so well together that a software developer could choose either Gtk or Qt at their whim, and it will "just work" and fit natively for either desktop environment, including look and feel, themes, services, and so on. The kickoff announcement is below. There is a mailing list on freedesktop.org for this just forming. Bryce ----- Forwarded message from "Bastian, Waldo" <waldo.bastian@...1100...> ----- Date: Fri, 2 Dec 2005 19:49:50 -0800 From: "Bastian, Waldo" <waldo.bastian@...1100...> To: desktop_architects@...701... Subject: [Desktop_architects] Portland: The Linux Desktop Integration Interface In the followup session aimed at making the live of ISVs easier wrt targetting the Linux Desktop two topics were discussed. The first topic addressed the issue of integrating with the two different desktop environments. The second topic addressed the issue of API/ABI stability. I will not be addressing the second topic here. During the meeting on Thursday a number of desktop integration points were identified that would benefit from having a well defined interface, independent of the desktop environment in use. In the follow up meeting it was discussed how we can move forward to make such common interface a reality. Nothing is real without a name and so "Portland" was adopted as the name of this initiative. Since the goals of Portland are very much in line with the mission of FreeDesktop.org it was agreed that FreeDesktop.org was the proper place to drive this effort. To speed up the process a task force of 4 people will be created with two representatives from both Gnome and KDE. Alex Graveley (Gnome) and George Staikos (KDE) agreed to lead the task force and will each invite one additional member. The goal of the task force is to prioritize integration points, solicit feedback from ISVs and identify existing functionality in Gnome and KDE that can be used to implement Portland, and possibly provide a first draft implementation. The task force will do a first report out before Linux.Conf.au (End of Jan, 2006) The goal is to have the first version of Portland ready for inclusion in LSB 4.0 which is scheduled for the end of 2006. In order to reach this goal it is important that Portland is available in early 2006 so that it can be included in distributions before LSB adoption. It is understood that the first version of Portland may not be able to address all integration points and that additional versions may follow. Cheers, Waldo Linux Client Architect - Channel Software Operation - Intel Corporation _______________________________________________ Desktop_architects mailing list Desktop_architects@...701... https://lists.osdl.org/mailman/listinfo/desktop_architects ----- End forwarded message -----

1 0

[cairo] GTK+ cairo canvas widget
by Bryce Harrington 06 Dec '05

06 Dec '05

----- Forwarded message from Damon Chaplin <damon@...1099...> ----- Date: Tue, 06 Dec 2005 12:13:58 +0000 From: Damon Chaplin <damon@...1099...> To: cairo@...278... Subject: [cairo] GTK+ cairo canvas widget Hi, I've been working on a GTK+ cairo canvas widget, goocanvas: http://www.dachaplin.dsl.pipex.com/goocanvas/ See the TODO file for things left to finish. I'm fairly new to cairo, so if anyone spots a problem with the cairo code let me know (I think the image drawing code may be wrong, for instance). Also, currently the layout of the text (using Pango) changes when you zoom in/out, even though I've used CAIRO_HINT_METRICS_OFF. If anyone knows a way to fix that I'd really appreciate it. Damon _______________________________________________ cairo mailing list cairo@...278... http://cairographics.org/cgi-bin/mailman/listinfo/cairo ----- End forwarded message -----

1 0

NEW: misc
by bulia byak 06 Dec '05

06 Dec '05

* Guidelines are made easier to pick: now you don't need to position mouse <i>exactly</i> over a guideline to activate it, instead there's a small position tolerance (1 screen pixel on each side of the guideline). * The keyboard shortcut for "Make selected segments curves" in Node tool is changed from Shift+K to Shift+U for better mnemonics. * In Calligraphic tool, Esc deselects as in most other tools. * In Selector, Ctrl+Enter enters the selected group (making it a temporary layer). Ctrl+Backspace leaves the current layer and goes one layer up in the hierarchy (but not to root). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

[Inkscape-tester] inkscape build report
by Bryce Harrington 06 Dec '05

06 Dec '05

The About Box error is persisting... You can see from the name of the snapshot that this is against the current snapshot. Bryce ----- Forwarded message from root <root@...1070...> ----- Date: Mon, 05 Dec 2005 17:21:04 -0800 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Mon Dec 5 11:09:58 2005 (Run 883) Snapshot: inkscape-20051205-0820.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 2 4 2 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == ui/dialog/aboutbox.cpp:88: error: no matching function for call to `Inkscape::UI::Dialog::AboutBox::size_request()' /usr/include/gtkmm-2.4/gtkmm/widget.h:510: error: candidates are: void Gtk::Widget::size_request(const Gtk::Requisition&) == Warnings == display/canvas-arena.cpp:87: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:87: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:133: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:133: warning: (perhaps the `offsetof' macro was used incorrectly) == Environment Summary == ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0

PDF Export/Import via Cairo
by Bryce Harrington 05 Dec '05

05 Dec '05

Hi all, I talked with Carl a bit more today about the PDF functionality with Cairo and what it'd take to use it with Inkscape. Here's some additional info. Carl, correct me if I've captured any of this wrong. Some clarification on libsvg, when Carl said he wasn't supporting it, I interpreted this to mean it needed another maintainer. He clarified this; the reasons he had forked libsvg from librsvg originally was to try out replacing its libart backend with a cairo backend. Now that librsvg uses cairo as it's back end, there's no reason for libsvg to be used, and in fact it lacks capabilities that are in librsvg. So... The plan going forward would be this. svg2pdf as it exists now is probably ok for a start; it's at least better than we got now, and fits within our existing system. I think it's mainly going to be a packaging issue to hook it into our extension framework. Beyond that, svg2png needs to be modified to use librsvg instead of libsvg. This is probably a fairly simple task, as svg2png is a really short bit of code. I told Carl about UberConverter. He wasn't sure if the design of Cairo's PDF functionality would match UberConverter's structure, so a crs2pdf via Cairo may not be the right approach. Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out. Bryce

6 5

PDF Support in Inkscape
by Bryce Harrington 05 Dec '05

05 Dec '05

Hi all, I've been noticing a LOT of requests for PDF/PS support in Inkscape. Either export or import or both. I'm fairly certain that this is the #1 top feature need for Inkscape right now. Over the past year or so, I've been fishing around for a volunteer to implement this. But unfortunately I'm coming up dry. Ain't no one I can find with an itch to implement this, not on a volunteer basis anyway. However, there are a TON of users with this need. Some of whom, I'm fairly certain, would be willing to pledge some money towards it. Maybe a little, maybe a lot, who knows. I think if enough people pitched in funds, we could actually make this happen. This is one feature I think we as a community could just force through, by hiring some mercenary to attack and kill it for us, hardcore style. Can you all tell me what you think? I really have no solid idea if enough people would be open to this plan. Are you a user that'd be willing to pledge $100 or more towards this? Are you a developer that'd be willing to commit to doing this work for some $k? Or do you have some ideas on how we could make this need get met? Please email me and let me know what you think. Bryce

9 12

Re: [Inkscape-user] PDF Support in Inkscape
by Bryce Harrington 05 Dec '05

05 Dec '05

----- Forwarded message from Bryce Harrington <bryce@...961...> ----- Date: Thu, 1 Dec 2005 18:24:51 -0800 From: Bryce Harrington <bryce@...961...> To: inkscape-user(a)lists.sourceforge.net Subject: Re: [Inkscape-user] PDF Support in Inkscape Hi all, Great feedback, thanks! And I got a possible solution to this problem that we could implement right now. I took the opportunity here at the desktop architect's meeting to grab Carl Worth and present the problem to him, to get a direct from the horse's mouth on Cairo's PDF. I mentioned that we'd heard that Cairo's PDF export wasn't good, and asked for the skinny on that. Here's the gist. Cairo's original mission was for screen and print perfect PDF, so what you see on the screen is what you get on the printer. Originally this was done by just creating a bitmap snapshot and embedding it in the PDF. This *looked* great, but of course is a heavyhanded solution. Later, someone created a new PDF backend for Cairo, but when they got ready to release 1.0 they saw that it was woefully inadequate, so Cairo 1.0 wasn't able to meet its PDF export capabilities. However, Carl says that actually has been their number one area of focus for the next release. This release is scheduled for Dec 15. He recommends we withhold making conclusions about Cairo's PDF until that release. Also, I asked about some sort of pluggable cairo-based svg-to-pdf converter, and this immediately clicked! He'd written a svg2pdf tool based on (an old) librsvg that does this. This is in the Cairo tree, and my guess is that this is something we could wrap up with an extension and immediately use. Perhaps the inkscape developers who are conversant with Cairo stuff could briefly mind meld with those who do extensions, and we can have Cairo-based PDF export in a matter of days. However, there are some caveats. In theory, this should work on Windows, but Carl's never tested it. So some of our Windows (and OSX) Inkscapers might want to put some time into this, too. I know PDF export is probably *most* important for users on non-Linux platforms so this testing is absolutely critical for y'all. Second, Carl says he's not providing any support for the libsvg module that this tool depends on, and in fact it's missing some features - filters, markers, transparency, etc. that we're definitely going to need. Thus, I think if we are going to invest time and/or money anywhere, this is the spot to do it. I'm not sure exactly what form that'd take - would we migrate code from inkscape into libsvg? Or the reverse? Would we collaborate with the librsvg people? Would we take over maintainership of libsvg? What do you guys think? Are we as a project interested in handling maintainership of libsvg? Regarding Google Summer of Code, I heard that they're also planning a Winter Summer of Code and/or a follow up next summer, but haven't heard confirmation. Also, even if they do, there's no guarantee Inkscape would again be accepted as a project... Also, I think the work may be more than one college kid could handle. ;-) So, I think we need to not count on Google for this one; if we do get in again, I think we'd want to divvy out the work in smaller chunks anyway, so even best case it wouldn't give us a total solution. Someone asked about the check from this last time... Yep, it just arrived via FedEx on Tuesday. :-) Early on we'd thought it might be good to put this towards some sort of sponsorship, so certainly adding it to the pool for a PDF solution is a possibility, if there's a strong enough concensus to use it for that. Btw, Dan Kegel is taking really good, thorough notes on the meeting; Kees and I were sitting next to him and admiring his good note taking. :-) http://kegel.com/osdl/da05.html Also it's kinda cool, Kees and I have had several people come up and say "Thank you so much for Inkscape!" One person said the thing they liked the most was how prolific, friendly, and strong our community was. :-) A couple other notes of relevance to Inkscape... There's something called RUDI that is getting a lot of discussion as a solution to better desktop integration - sounds pretty cool. The C++ ABI breakage has gotten a lot of discussion; Kegel says the gcc devs have committed to stabilizing their ABI so these problems may diminish. There's a strong feeling that there should be a stable package of GNOME/etc. libs for Windows, so each ISV/project doesn't have to statically link and ship their own copies. Carl and Mike Shaffer of Mozilla were discussing a lot about Cairo performance; sounds like there's much work going on in that area. John Waugh of Ubuntu told me about something called 'Dogtail' that sounds like it's a powerful way to do testing, and suggested we use that for Inkscape. An idea occurred to me - some of the exercises we're doing here with pens and cards seem like they'd work *much* better on top of Inkboard. I think it would be useful to record an inkboard session and then create 50+ simulated sessions all talking to the same document, and fix whatever breaks. Inkscape could totally rule as a conference collaboration tool. Bryce On Thu, Dec 01, 2005 at 12:32:01AM -0700, Michael Moore wrote: > > I've been noticing a LOT of requests for PDF/PS support in Inkscape. > > Either export or import or both. > > > > Over the past year or so, I've been fishing around for a volunteer to > > implement this. But unfortunately I'm coming up dry. Ain't no one I > > can find with an itch to implement this, not on a volunteer basis > > anyway. > > > > Can you all tell me what you think? ----- End forwarded message -----

4 6

Compile error for About screen?
by Bryce Harrington 05 Dec '05

05 Dec '05

I just did a cvs up and rebuild, and got this error: /home/bryce/src/Inkscape/inkscape/src/ui/dialog/aboutbox.cpp: In constructor ` Inkscape::UI::Dialog::AboutBox::AboutBox()': /home/bryce/src/Inkscape/inkscape/src/ui/dialog/aboutbox.cpp:88: error: no matching function for call to `Inkscape::UI::Dialog::AboutBox::size_request( )' /usr/include/gtkmm-2.4/gtkmm/widget.h:510: error: candidates are: void Gtk::Widget::size_request(const Gtk::Requisition&) make[2]: *** [ui/dialog/aboutbox.o] Error 1 make[2]: Leaving directory `/home/bryce/Build/Inkscape/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bryce/Build/Inkscape/inkscape' make: *** [all] Error 2 In case this was just due to out of date autoconf stuff, I'm doing a make distclean and a full rebuild. Bryce

3 3

Wiki Spam, more security. time for accounts yet?
by Alan Horkan 04 Dec '05

04 Dec '05

The current anti spam system doesn't seem to be effective anymore and it is quite annoying to use, at least with a login system I only have to worry about it once and then save the settings in my browser. (The notSPAM block must be typed every time and it is quite frustrating even the option to use logins and avoid having to confirm everything each time woudl be a big help). I cleared some SPAM links from the main wiki page inkscape-devel(a)lists.sourceforge.net and then noticed the sneaky beggars had added blocks of hidden links which do not actually show up on the page. Even if you decide logins are too much of a restriction, I do hope the security can be cranked up some other way. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

8 10

[Inkscape-tester] inkscape build report
by Bryce Harrington 04 Dec '05

04 Dec '05

----- Forwarded message from root <root@...1070...> ----- Date: Sat, 03 Dec 2005 17:21:03 -0800 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Sat Dec 3 03:55:34 2005 (Run 876) Snapshot: inkscape-20051203-0220.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 2 7 2 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == ui/dialog/aboutbox.cpp:88: error: no matching function for call to `Inkscape::UI::Dialog::AboutBox::size_request()' /usr/include/gtkmm-2.4/gtkmm/widget.h:510: error: candidates are: void Gtk::Widget::size_request(const Gtk::Requisition&) == Warnings == display/canvas-arena.cpp:87: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:87: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:133: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:133: warning: (perhaps the `offsetof' macro was used incorrectly) removeoverlap/solve_VPSC.cpp:183: warning: comparison between signed and unsigned integer expressions removeoverlap/solve_VPSC.cpp:240: warning: comparison between signed and unsigned integer expressions removeoverlap/solve_VPSC.cpp:244:2: warning: no newline at end of file == Environment Summary == ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0