[Gimp-developer] path file format spec?
I try to create a converter from a gimp path file to sketch. I tried to understand the path format, but running into trouble. I tried to look a bit in the internet if i can find some specs about the file format, but didnt find anything. If someone know, where to look let me know :) Thanks, Roman -- www: http://www.romanofski.de email: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] writing german online help
I looked a bit around (webpages, irc ..) to see what is done for gimp help, ecpecially german one. If i'm right, there is nothing and i would start to write a new one for the gimp 1.3 from scratch. I cant find anything related to the gimp-help project at the newer webpage. So, if someone could point me to a ressource regarding this project it would be fine. As far as i know, the gimp help is written in html and viewed with the gnome help browser. At least, thanks for some ideas. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Sat, Jul 26, 2003 at 05:08:00PM +0100, Alan Horkan wrote: the archives are either completely broken or just severely delayed. it is the 26 of July and the archive still does not show any messages for July. Yeh, you're right. I'll check the other options first (gimp-help-2) and write my suggestions and comments. Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 02:57:49PM +0200, Daniel Egger wrote: Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have? Debian GNU/Linux (sid - unstable) Sure, but in that case we can still split them up a finer granularity on structure level, say: give every subsection it's own file instead of just every section. k - lets see ... I'm not familiar with the help-xml syntax, but maybe i'm on the right way. For example (gimp-help-2/help/C/toolbox/zoom.xml): lang name=en variablelisttitleOptions/title varlistentrytermOverview/term listitem para The available tool options for Magnify can be accessed by double clicking the Magnify tool icon. /para /listitem /varlistentry /lang lang name=de variablelisttitleOptionen/title Or should the lang specified as an attribute? like: variablelisttitle lang=deOptionen/title Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 10:45:50AM -0400, Carol Spears wrote: Roman, i invested money to learn docbook, i suspect it was to keep up a broken system and broken people. i would send you $5 to try to rid yourself of this dependency on docbook, at least for your own sake, try to get a better deal for yourself from prof and docbook authors. i think it destroyed syngin. syngin was beautiful. look at the commit list. what is a good and proper way to say Something stinks so badly and i suspect it is name of stink maker. and not piss anyone off and be clearly understood. carol What can i say - i was wondering what this project needs to get done at first: the managment or a newer gimp-help? I mean - i dont care about the technics to get a good help. I just want to create a help, nothing more. Iam a complete newbie here and dont know what'll the best for a help, rather than for the contributors. If Docbook will be the best to generate a help - okey, i'll write the help in docbook. So, finally - i'll write it in XML as daniel wants. I wanna get the help done, because i've _now_ some spare time and i think _now_ is the best time to _help_ the gimp. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 04:08:09PM +0200, Daniel Egger wrote: I'm submitting a little patch for introduction.xml and minor fixes in the plainhtml.de.xsl.in. Some points to consider: 1. The German Umlauts are really annoying. Are there some pre-processors, which checks the umlauts and replaces them with an utf entity (or the predifined HTML umlauts... what else...)? If not, it think i'll write a little script. I forget them every time... 2. How do i create a better patch? I tried: cvs diff -R help/ foobar.patch but it looked nothing suitable for submitting. 3. How do you planed the reviewing process. Should i create a patch, submit this to you and you'll check it in the cvs repository? Maybe it'll be better, that any editor has an cvs access. The reviewing process goes on text crosswise. Everyone is checkin the help from another editor? Thats it so far. Tell me if the introduction.xml is okey and i can go any further. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
okey.. i'll learn that i've to attache that damn file on the mail, when i mention it. .. brr Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] diff -ru /tmp/gimp-help-2/help/C/CVS/Entries help/C/CVS/Entries --- /tmp/gimp-help-2/help/C/CVS/Entries 2003-07-27 19:01:48.0 +0200 +++ help/C/CVS/Entries 2003-07-27 18:39:46.0 +0200 @@ -1,10 +1,10 @@ /.cvsignore/1.1/Sat Jul 27 15:47:32 2002// -/Makefile.am/1.4/Sun Jul 27 14:00:03 2003// -/gimp.xml/1.10/Sun Jul 27 14:00:03 2003// /glossary.xml/1.3/Sun Dec 29 02:50:07 2002// -/introduction.xml/1.6/Sun Jul 27 14:00:03 2003// -/not_yet_written.xml/1.2/Sun Jul 27 14:00:03 2003// D/filters D/images D/legal D/toolbox +/introduction.xml/1.6/Sun Jul 27 15:46:37 2003// +/not_yet_written.xml/1.2/Sun Jul 27 15:46:37 2003// +/Makefile.am/1.4/Sun Jul 27 16:39:46 2003// +/gimp.xml/1.10/Sun Jul 27 16:39:46 2003// diff -ru /tmp/gimp-help-2/help/C/filters/CVS/Entries help/C/filters/CVS/Entries --- /tmp/gimp-help-2/help/C/filters/CVS/Entries 2003-07-27 19:01:48.0 +0200 +++ help/C/filters/CVS/Entries 2003-07-27 16:40:41.0 +0200 @@ -1,2 +1,2 @@ -/filters_introduction.xml/1.2/Sun Nov 3 10:16:33 2002// D/blur +/filters_introduction.xml/1.2/Sun Jul 27 13:19:15 2003// diff -ru /tmp/gimp-help-2/help/C/introduction.xml help/C/introduction.xml --- /tmp/gimp-help-2/help/C/introduction.xml2003-07-27 16:00:03.0 +0200 +++ help/C/introduction.xml 2003-07-27 18:52:34.0 +0200 @@ -27,7 +27,7 @@ zusammengesetzt aus den englischen Worten acronymGNU/acronym oder General Image Manipulation Program, was im Deutschen soviel bedeutet wie Universelles Bildbearbeitungsprogram. acronymGIMP/acronym ist -auml;szlig;uerst vielfauml;ltig einsetzbar fuuml;r eine Vielzahl an +auml;szlig;erst vielfauml;ltig einsetzbar fuuml;r eine Vielzahl an Aufgaben einschlieszlig;lich Photonachbearbeitung, Bildkomposition und -malerei. /para @@ -47,9 +47,26 @@ acronymGPL/acronym provides users with the freedom to access and alter the source code that makes up computer programs. /para + + para lang=de + acronymGIMP/acronym's Stauml;rken liegen vor allem in der freien + Verfuuml;gbarkeit aus vielen Quellen und vielen Plattformen. Die meisten + acronymGNU/acronym/applicationLinux/application Distributionen + benutzen den acronymGIMP/acronym als Standard Anwendung. Auch fuuml;r + andere Betriebssysteme ist der acronymGIMP/acronym erhauml;ltlich, wie zum + Beispiel productnameMicrosoft Windows/productname oder Apples + productnameMac OS X/productname (applicationDarwin/application). + Ein wichtiger Punkt aber ist, dass der acronymGIMP/acronym nicht + Freeware ist. Es ist eine acronymOSS/acronym or Open Source Anwendung, + welche uuml;ber die ulink url='http://www.gnu.org/license/gpl/' + type='http'acronymGPL/acronym Lizenz/ulink vertrieben wird. Die + acronymGPL/acronym gibt den Benutzern die Freiheit auf die Quellen + zugreifen und diese verauml;ndern zu kouml;nnen. + /para sect2 id='introduction-platforms' -title lang=enKnown platforms/title + title lang=enKnown platforms/title + title lang=deVerfuuml;gbare Plattformen/title para lang=en The acronymGIMP/acronym is possibly the most supported image @@ -71,21 +88,58 @@ productnameIRIX/productname, productnameOS/2/productname, and productnameBeOS/productname. -/para - -para lang=en + /para + + para lang=de + acronymGIMP/acronym ist wohl heutzutage das mit am meisten unterstuuml;tzte + Bildbearbeitungsprogramm. Der acronymGIMP/acronym ist erhauml;ltlich und + funktioniert auf folgenden Plattformen: + productnameacronymGNU/acronym/Linux/productname, + productnameApple Mac OS X (Darwin)/productname, + productnameMicrosoft Windows 95, 98, NT4, and 2000/productname, + productnameOpenBSD/productname, + productnameNetBSD/productname, + productnameFreeBSD/productname, + productnameSolaris/productname, + productnameSunOS/productname, + productnameAIX/productname, + productnameHP-UX/productname, + productnameTru64/productname, + productnameDigital UNIX/productname, + productnameOSF/1/productname, + productnameIRIX/productname, + productnameOS/2/productname, and + productnameBeOS/productname. + /para + + para lang=en The acronymGIMP/acronym can be easily ported to other operating systems because of its source code availability. -/para + /para + + para lang=de +Durch seine Quelloffenheit, kann der acronymGIMP/acronym leicht auf +andere Plattformen portiert werden. + /para + /sect2 sect2 id='introduction-help' -title lang=enThe GIMP-Help system/title + title lang=enThe GIMP-Help system/title + title lang=deDas GIMP-Hilfe System/title
Re: [Gimp-developer] Wrong terminology in color picker tool
On Mon, Jul 28, 2003 at 12:53:00PM +0200, Daniel Egger wrote: Hija, I just noticed that GIMP uses the label Radius to describe a slider which is effectivly describing the size of a square area. This seems pretty misleading to me, what about edgelength or alike instead? I think Size would be more convenient, because every tool use size ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gimp-help-2
On Mon, Aug 18, 2003 at 06:38:06PM +0200, Sven Neumann wrote: Translation of the help pages is another subject that should be discussed beforehand. I don't think the current approach of translating the XML source in place will scale well when the number of translations increases. There are some tools available that automate the process of extracting translatable strings from XML sources and merging the translations back. We should consider to use them. Maybe you mean, writing the translation to *.po files? I saw this, during the work on a new setup of a zope server. We used Plone and they translated all these english stuff into other languages using *.po files. I don't know which will be best technical way for write a translation. Daniel said, that this way isn't bad as it seems, because you can controll the granularity of the generated files or split up the xml docs. Perhaps this mail can get a discussion started. We should also try to involve more people early. I suggest we ask for volunteers on the gimp-user list and other user forums. Yes - i agree. We need many contributors to get a good manual done. I think, the best way is to get a section on the gimp page (i asked Daniel earlier). There we can show the current status of the manual, and ask for help. Additionally we can setup some help pages, to get involved. I think, we need some writers, who are responsible for a language file (the translation file). So, to summarize my opinion. I think we need: - a webpage where we can upload the current cvs for the online user - a status page - a contributing page, where everyone can get involved Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gimp-help-2
On Mon, Aug 18, 2003 at 07:40:14PM +0200, Sven Neumann wrote: I don't really care. I just wanted to be sure that you considered using these tools. If you dislike them and decided to go for a different solution, I'm fine with that. I think, that Daniel Egger and Mel Boyce setup the newer gimp-help-2 module. For this reason, i think that Daniel know exactly what he is doing, to get a good documentation done. I can currently agree with him. If i understand you right, you just wanted to take care, that no one invest time to get a new documentation done which is completly useless. So, we're on a good way to get a basic documentation done, which is useable for the Prerelease of the GIMP 2.0. Iam looking forward to get this done and hope, that more contributors join us, when a site is up ... - a webpage where we can upload the current cvs for the online user - a status page - a contributing page, where everyone can get involved That's exactly what I was trying to say. I was asked today on #gimp how to contribute to gimp-help and I wasn't sure what to respond. A web-page to refer people to would certainly help a lot. I'll setup up some pages for the module, but where can i upload these pages? A good way to update the status of the docs is an account, where i can sync my help and the help docs on the server. If it isn't possible to upload these pages to the current website yet, i'll create a temporary location for the these docs. This isn't the best way, because temporary means difficult for the users and upcoming contributors. I uploaded docs of the gimp-help-2 module on a university server, since we might get a section on the gimp page. http://www.kuhcampus.de/~roman/gimp-help-2/ Maybe one of the GIMP Website Team can help me? Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Tue, Aug 19, 2003 at 12:23:06AM +0200, Sven Neumann wrote: Why don't you simply write it all in UTF-8? Using HTML entities seems akward and error-prone. The helpbrowser plug-in is fully UTF-8 aware and if you use an editor that copes with UTF-8, you can simply use umlauts in your texts. Its written with UTF-8 Entities, so i think this thread is deprecated .. The only thing was a correct mapping of the umlauts. I setup my editor correctly and now i can write the docs without typing in the entities. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Tue, Aug 19, 2003 at 11:50:51AM +0200, Sven Neumann wrote: Excuse my ignorance, but what are UTF-8 entities? I had a look at the stuff in CVS: secondaryEinfuuml;hrung/secondary and I would have expected: secondaryEinführung/secondary AFAIK, you can't write german umlauts in xml files, which are utf-8 encoded. The UTF-8 Entity for the german umlauts are mapped in gimp.xml to html entities. I think, daniel made this for contributors, because the most know the german umlauts as HTML entities. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gimp-help-2
On Wed, Aug 27, 2003 at 11:33:50AM +0200, Sven Neumann wrote: Let's call each help-tree, either installed by gimp-help or by a plug-in, a help domain. The problem I see is that the current proposal doesn't define a way to link between help domains. While for example the freetype plug-in might install it's own help file(s), there is no way for the author of the text-tool help to link to this page and the freetype help author cannot link to the text tool documentation. This problem could be solved by allowing links in the help pages to point to the registered identifiers instead of pointing directly to HTML pages. So when the text-tool help wants to link to the move-tool, it would use something like link gimp-help:href=gimp-move-tool / and the help-browser would have to use it's mapping file to find the HTML page from the identifier. This is a good way to share content. I mean - if i'm writing about the text tool, i dont need to write about hinting, font shapes and anything specific about fonts, i can point the user for more information to e.g. freetype. Okey - background information is a part for the glossary. For example, if i would need some help about a text tool, i'll get a short help if i use F1. Okey... maybe then, i want to read any further, because fonts are interesting and this stuff about freetype also. The worst case is, if there is no freetype plugin installed, the help will not be available. So - if i link to other help pages, the help browser or the background logic has to decide if the help is available or not. If the help isn't there, the link shouldn't be displayed, because the reader couldn't get the information which is offered. Is it possible and not to hard to implement such things? A second thing is, how fast can the available help docs be parsed. If i understood you right, the helpbrowser also knows other references. If the user want a short help, the help browser parses these xml files and go straight forward to the subject (or display an error - not yet written). But if the helpbrowser needs to parse references and needs to decide things (is this help available or not), will it take to much time to display the short help item? Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[Gimp-developer] LinuxUser article about GIMP 2.0
I wrote an article for the german LinuxUser magazine, and want to ask the developers, to approve the article, before i'm going to publish it. I hope, that i didn't make to many mistakes. So - any ideas and help is appreciated. The article can be found under following url: http://www.kuhcampus.de/~roman/LinuxUser/gimp.html Thanks for your help. -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] WikiWordOfTheDay
On Mon, Sep 08, 2003 at 11:52:10AM +0200, David Neary wrote: Hi all, I had a few ideas about collaborative content creation for the website and the documentation project recently, and thanks to Carol's forethought, we have the means to do this at our fingertips. [..] So there's the idea. To work, it'll need the cooperation of the documentation team, the web team and the user and developer communities. Since i used a wiki to collaborate content i love them. The advantage of a wiki is, that maybe everyone can contribute to the docs in small pieces. Unfortunatly, we have some problems for new users and contributors to getting involved for writing docs: 1. Learn how to contribute (what is easier to lern: writing XML docs or learn the wiki syntax) 2. If we have some docs on a wiki page, how is it possible to convert them to XML? Maybe it costs more time to convert the wiki docs, than a new contributor will lern XML ... 3. How can we add existing docs to the WIKI? 4. How about translations? The user must be able to write a translation of a given wiki page, in my opinion. So, in facing this problems i thought, that it'll be better to do the following: 1. Make the project page of the user manual as a wiki page. 2. Let contributors add docs. I think it isn't a problem of getting contributors, which are writing docs. The problem might be, that most poeple write some pieces and no one checks that. For that problem, i think it isn't necessary to move the hole gimp-help-2 project to the wiki. I think, it'll be better to take some good pieces for the gimp-help-2 from the WIKI and include them into the existing docs. To summarize that, i think a wiki page will be good to stay connected with the current documentation (its great to post news and some short introductions, discuss new things etc.). But i dislike a wiki, to fetch docs for the gimp-help-2. I think, its an additional expenditure to the existing project. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] WikiWordOfTheDay
On Mon, Sep 08, 2003 at 05:02:53PM +0200, Daniel Egger wrote: Great idea. I like it. The only thing missing is a halfautomatic DocBook/Wiki gateway to synchronize content between the colaboration Wiki work and the real documentation with additional markup. Okey - i think we need some naming conventions between english and translated docs. Maybe something like GimpToolboxEllipsel-de ? I like to move the project pages to the wiki ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[Gimp-developer] [OT] looking for an international internchip
Sorry for that not GIMP related Mail. In order of my studies, i've to complete an internship for approx. 3-4 months next year. I'll prefer an internship, which is not located in germany and has something to do with linux. UI-Design, Web-Technologies or something related will be interesting, but not important. I would be grateful, if someone could point me to a good resource like a company homepage or related links. Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] resources for presentations
I was thinking about a page with ressources for users who made presentations about the GIMP. During my work on some presentation stuff for the university, i thought, that it'll be usefull to get images to demonstrate some atools. But ... after thinking about this, i don't know if this idea is good. I mean, most people invest work in her presentation stuff and i think, that someone who wants to gather ressources from others, he has to ask. For this reason, it might be better, to create a document in the WIKI and append Links to docs, which will share other GIMPers for presentation purposes. Others can append images as well, so that we can demostrate some tools on this images. But this links has to be made by the persons herselfs, which want share their stuff. Maybe others can tell me her opinion about this idea. I would like to share some docs and pictures for presentation purposes. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] gimp-help-2 status and suggestions
After the frensh translation made the way into my gimp-help-2 sandbox, Sven and Brix are pointed me to the current directory structure of the module. In my current point of view, the current help/C directory is obsolete and should be replaced with a newer structure. This is the actual structure. I made a find ./ -type d in the gimp-help-2 and removed the CVS directorys: ./ ./help ./help/C ./help/C/C ./help/C/de ./help/C/filters ./help/C/filters/blur ./help/C/images ./help/C/images/glossary ./help/C/images/tool-options ./help/C/images/toolbox ./help/C/images/toolbox/de ./help/C/legal ./help/C/toolbox ./help/stylesheets I recommend the following structure (gimp-help-2 is the top directory): ./ ./src ./src/filters ./src/filters/blur ./src/images ./src/images/glossary ./src/images/tool-options ./src/images/toolbox ./src/images/toolbox/de ./src/images/toolbox/fr ./src/images/toolbox/se ./src/legal ./src/toolbox ./src/stylesheets ./html/C ./html/de ./html/fr ./html/se The ./src directory contain all the sources, including XML files, stylesheets and images. I would suggest, that the generated html pages are going into a source seperated directory which is html. I added the se directory which isn't in the actual gimp-help-2, but scizzo is on it, to fill out the directory with content in the future. The language dependend image files (like screenshots) are going into seperated directories (./src/images/toolbox/de). I hope, that i didn't missed something specific. I'm looking forward to hear opinions from all the gimpers. Additionally, i want to inform you about the status of the gimp-help-2. The gimp-help-2 document the current tools (except the color tools) in german and france, as well as in mostly english. Unfortunately, the english part is mostly undone and i hope, syngin will close the gaps :) Alan Horkan is working on the gfig plugin, which is mostly written. Scizzo invested time, to update the structure of the documentation and how the manual structure should look like when its done. I think, that we will need a native english speaking person, who can check over the docs. Okey.. people who checking the docs and help the writers are always appreciated. I added a whishlist for users to the gimp wiki. This would help us to stay focused on more important things which are needed by the users. To sum up, thanks a lot for all the work which is now in the module and people are working on. There is much work to do and i'm looking forward to inform you with all the changes which are changed in the next months. Thanks and Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 status and suggestions
So i revamped the purposal and it looks now like this: ./ ./src ./src/filters ./src/filters/blur ./src/images ./src/images/glossary ./src/images/tool-options ./src/images/toolbox ./src/images/toolbox/de ./src/images/toolbox/fr ./src/images/toolbox/se ./src/legal ./src/toolbox ./stylesheets ./html/C ./html/de ./html/fr ./html/se I moved the stylesheets directory into the source root. I will change it in the next days, after Daniel will give me the ok. No one has declined the new structure purposal, so i think, that everyone on gimp-help-2 gave this implicit OK to change it? Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 status and suggestions
On Sun, Nov 23, 2003 at 08:19:38PM +0100, Daniel Egger wrote: Go! :=) Yay! Regarding xinclude: I've a few ideas I'll try the next few hours. It seems like a really worthwhile feature to me so let's check how portable/stable it is... I tried it with some docs and it rocks. Unfortunately, i'm running into trouble with the german umlauts. Do you've a solution for keeping the umlauts ? Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 status and suggestions
So, one step ahead to finish the gimp-help-2 move into the new source structure, which finishes the source tree move and add the frensh translation and content from Julien and Raymond. Before i type in my last cvs commit i want to verify one exception of my proposal: the image directory. I want to suggest, that we move the image directory containing all the png files into the html directory (where the generated html files are after a make) and leave the source images (*.XCF Files which are mostly screenshots) in the /src/images directory as suggested. That seems a bit more reasonable for me, because we're separating the image sources from the normal content screenshots. Additionally, we don't need to move them into the /html directory or wherever. Yeah, we're saving one move! So, if no one are against this suggestion, i'll check them in as i mentioned here. After that, i'll write a status mail of the actual sources. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] gimp-help-2 updated
Well, well, the source directory is completely updated and i suggest, that you create a new gimp-help-2 sandbox first. I added the frensh translation to the files and had to add my previous changes (see document structure) most of the modules, because the file structure of the frensh translations was rather old. It is necessary to stay in sync with the gimp-help-2 HEAD and maybe apply cvs patches to your local files to prevent this in the future. Another point, which i figured out is the mixed language content in the xml files. This is not a big problem, but i want to admit, that one mistake in an xml file, will crash all the other languages in that file (and even the hole manual). So, take care of editing the xml files before you check them in. Maybe, we should break them into seperate files in the future, because of the overhead of seperate languages. The things which are todo for me now are: 1. add the generation of swedish content 2. remove the entities 3. add the XIncludes. I'll remove the entities, which are mapping the german umlauts to the correct unicode entity (if i'm right). If i understand Daniel correctly, we should be able to write normal umlauts with a proper UTF-8 encoding. It wasn't clear enough for me, when we discussed the UTF-8 issue on the mailinglist. The problem is for me, that i cannot use XIncludes, when the documents use ouml; to generate an german oe. What should we do now: 1. switch completely to UTF-8, 2. use the proper unicode entities (eg. oe for #246;) for printing umlauts and special language dependend characters? The switch to UTF-8 was not recommended by Daniel, where he points out, that this might break some asian language contributions (if there are some, who wants to help). I suggest, that we don't switch to UTF-8 and use the unicode entities to get a valid XML file. Resulting changes: - 1. xml sources are going now into $GIMP-HELP-2/src (for XML sources) $GIMP-HELP-2/images (for image sources) and subdirectories. I think, we should use the structure of the documentation [1], which was setup by Niklas, to structure the source files. Okey, not deeply like the structure purposal, but likewise. 2. The frensh translation need some screenshots. I seperated the german-only shots in different directories, so i would suggest to put them in here: $GIMP-HELP-2/html/images/toolbox/fr The binary images are going globally into: $GIMP-HELP-2/html/images and its subdirectories. 3. I updated the README file, which has now the structure of the whole manual and the structure of a doc file. The frensh translators should adding some translations for the tool call of a dialog or tool. 4. I found some uncommented code in the frensh translation. It would be usefull, that the translator document somewhere, in which document he has uncommented code. We can use our WIKI for that. Okey, thats all what i have ... Thanks to all authors for the good work and happy writing :) References: --- [1] - http://wiki.gimp.org/gimp/StructureOfTheDocumentation Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 updated
On Wed, Dec 03, 2003 at 07:38:00PM +0100, Raymond Ostertag wrote: On Wed, 3 Dec 2003 12:18:15 +0100 Roman Joost [EMAIL PROTECTED] wrote: What do you call uncommented ? Do you mean not translated ? No, sorry for the bad description. I mean commented code which were of course translated. hum, still difficult to understand... It's text in french that don't exist in english ? No no - wrong way *G The text was translated into frensh but was commented. Maybe i use the wrong word for comment something, eg: !-- para lang=foobar/para -- ...maybe its from patching the source.. i dunno For this it could be enough to open a new paragraph with a special attribut para lang=en stat=TO_BE_TRANSLATED /para But the best thing it's to avoid doing this. yes Another thing which still remains for us is, to produce now utf-8 encoded documents without the gimp.xml entities. I'll try translate the existing docs to utf-8 without the entities. Please give me some feedback how well it works. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] gimp-help-2 status
This mail is only a tiny status mail of the current progress on gimp-help-2. With Raymonds help i'm now be able to build the help with UTF-8 encoded XML files, which are xincluded in the gimp.xml file. All of the entities are gone and i can replace the last files with the correct unicode characters. I'm looking forward to replace all the old files with the newer UTF-8 stuff on weekend. That means, the CVS should be up to date soon (i've some frensh files on hold). Julien and Raymond are working like machines.. i can't get the files into the CVS as they produce them :) The manual itself looks promising. We got some additional writing power for the english content. Daryl Lee takes care about the english content and Niklas can produce (or better: is producing) swedish content. We, Niklas and i, ran into bit trouble lately, when we tried to produce the manual with some swedish content. It seems, that docbook doesn't have any swedish support?! Additionally, we get some feedback from Ramanan Selvaratnam. He'll support us with additional information about free software backgrounds (sorry, i didn't have the time lately, to read all the mails) and will provide content in 'Tamil' - a truly global diaspora with a growing interest in FS. Daniel pays attention to him, because he has the most knowledge about the gimp-help-2 project. Hopefully, i've some more time over new year's eve to write german content and stay in sync with Raymond and Julien. I'm looking forward to have a meeting with the Gimpers in Berlin on the 20C3 and a good manual for the Gimp 2. I hope i didn't missed something ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 - TODOs and ideas
On Thu, Dec 18, 2003 at 12:44:16AM +0100, Daniel Egger wrote: Am Mit, den 17.12.2003 schrieb Roman Joost um 21:30: 1. Renaming of the current XML files, that the corresponding help ids: app/widgets/gimphelp-ids.h. This is mostly done by me. I'll check the changes in as soon as possible. Huh? Probably it's just me being dense... Heh - no. I shouldn't write mails during a lecture ... The existing XML files are renamed to the name of the help ids in $GIMP/app/widgets/gimphelp-ids.h, eg: airbrush.xml is now: tool-airbrush.xml 2. Adding XML files for all the other help ids, especially for the plugins. This would help the gimp developers to test the help browser. The content should look like the one in: src/not_yet_written.xml. The structure of each document should look like: a) a phrase like: this document has not been written b) author name c) plugin name, additional information, etc d) an email adress and a contact person, where a person can send as (plain) documentation This has caused quite some gripes back in the good ol' times. What about using xinclude tricks to supply the content of one template document as the source for yet-to-be written files? This approach is documented in http://www.sagehill.net/docbookxsl/ however I haven't had the time to verify that it works with xsltproc yet. I'll have a look at it ... 3. This item was not discussed on the IRC, but maybe an interesting thing to add: an example how to use a tool|documented item. This should look like eg. How do you make a rectangular selection. By explaining this example step by step, i think, it'll make the life much easier for the user. We talked about this earlier and seemed to have agreed that this is a nice idea. :) Okey - added this to the WIKI ... We've now only a TODO list on the WIKI. Every gimp-help-2 developer can pick a term and solve it. This reminds me to bugzilla. Well, this implies, that someone feels responsible for his part on gimp-help-2 (writing content or something else) and can use bugzilla. How do think other gimp-help-2 members about this? Maybe the project needs a bit more contributors, for making sense... I don't think it makes sense to have formal assignments of specific topics as this would take away most of the fun a volunteers project should make. Merry Christmas, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 news ...
On Fri, Jan 09, 2004 at 11:10:46PM +0100, raymond ostertag wrote: Le lun 05/01/2004 ?? 00:49, Roman Joost a ??crit : a) Screenshots should be made with the standard GNOME theme and a generic font (like Bitstream Sans). Standard GNOME theme is ? I don't remember but on my Mandrake the standard is Galaxy ?? I'm sorry. Standard GNOME theme is genglish, i mean the Gnome Default Theme. b) If we make some compositing images, we should provide the source file. The others should be able to make the same image with translated text from it. Julien and Raymond made some cool diagrams in SVG. Unfortunately i can not translate them, without discarding the font data. Well I made the SVG with sodipodi 0.33 with the fonts installed on my Mandrake 9.2. My first goal was to release this in XCF with text layers but the SVG import don't transform the Sodipodi text in Layers (may be I miss something). So finally I released a SVG that you can edit with Sodipodi (the fonts used are AD MONO, binary). I you think we should use only a few fonts (what you call generic fonts) please give us a list of the font that we can use (we need at least 3 fonts) and write this somewhere on the Wiki. Yes. I just want to make sure, that the generic font is available on every system. Please make a suggestion, if you don't have the Bitstream fonts installed. Well, the microsoft ones are used on most systems as well ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 news ...
On Fri, Jan 09, 2004 at 10:06:50PM +0100, raymond ostertag wrote: Le lun 05/01/2004 ?? 00:49, Roman Joost a ??crit : 1. The problem, that the whole content is mixed up after the generation is now fixed. The problem was, that only the dtd in gimp.xml was wrong. It seems, that this was my fault and i'm sorry for that. I had a bit of time to add some german content and make some corrections, during the little meeting with Sven and Simon in Berlin. Unfortunately, i couldn't motivate Sven to finish the install target ... What is the statut now ? Since christmas I only have a few html files with only xinclude in it. It's always possible to work with the old framework but I'd prefer work with the new one with the TO BE WRITTEN texts. A new cvs update should bring you all the changes. I hope, that the anonymous gnome cvs servers are now in sync with the other ones ... If not, drop me an e-mail and i'll send a tarball to you and Julien. The gimp.xml xincludes now the xml files and the entities are gone. There is additionally a tools.xml in the toolbox directory, which xincludes the tools. Have a look at gimp.xml and tools.xml. I don't find in the CVS the doc I written myself : rewritten Path tool, Dialog layer ? Do I have to resent them to you or not ? Well i know this shouldn't happen, but it has been overlooked by me. Sorry for that. I merged it into the path xml file and comitted it to the cvs. Thanks for your work! Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 news ...
On Sun, Jan 11, 2004 at 03:23:30PM +0100, Sven Neumann wrote: Hi, The DTDs are absolutely necessary in order to process the files. You cannot expect things to work if the DTDs are missing. Also you shouldn't use the DTDs from the network but have them installed at your computer. You will need an XML catalog file that tells your XSLT processort where the DTDs are found on your disk. Usually this file lives in /etc/xml. AFAIK it is correctly installed on recent RedHat systems; it is known to be broken on Debian and I don't know about other distributions. For Debian there is a script that attempts to fix the catalog file. Use it at your own risk: I looked at http://www.sagehill.net/docbookxsl/UseCatalog.html#d0e3162 and it seems for me, that we don't need a DTD declaration on top of gimp.xml if the catalog file is present and the corresponding environment variable is set. I tried to build the manual after removing the declaration and the translation process works fine. If this would work on other machines, i'll remove the DTD declaration on top of gimp.xml. Are there any concerns about that or do i missed something? Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 news ...
On Tue, Jan 13, 2004 at 11:32:21AM +0100, Sven Neumann wrote: Roman Joost [EMAIL PROTECTED] writes: I looked at http://www.sagehill.net/docbookxsl/UseCatalog.html#d0e3162 and it seems for me, that we don't need a DTD declaration on top of gimp.xml if the catalog file is present and the corresponding environment variable is set. I tried to build the manual after removing the declaration and the translation process works fine. If this would work on other machines, i'll remove the DTD declaration on top of gimp.xml. You loose the ability to validate the file w/o explicitely specifying the DTD file. Also I am surprised that you can process the file w/o the DTD. Aren't you using any entities? What would be the advantage of removing the DTD declaration? We don't use entities anymore (except for one in gimp.xml). I thought, that the advantage of removing the DTD declaration would be no more hassles with building the manual. The XML book from www.sagehill.net explains, that a (correct) catalog file would be the best of both - local and network DTD. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] gimp-help-2 preperations for our 1st release
We're going to make a first release of the gimp-help-2. I want to inform the authors, to have a look over their written content and make sure, that the release will not include major spelling or grammar errors. The freeze of the sources will be on next wednesday the 11th. Hopefully, this release will get some more attention of writing content and fixing tiny errors for the manual. So, keep up the good work and let me know if there are any problems regarding the release. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] gimp-help-2 preperations for our 1st release
On Tue, Feb 03, 2004 at 08:50:27PM -0500, Daryl Lee wrote: On Tue, 2004-02-03 at 18:22, Niklas Mattisson wrote: Hey again, ... * src/toolbox/tool-*.xml should change the line Tool Call to something else. This is not correct english and I can't seem to find good translation for the words either. Has anyone considered Tool Menu Navigation? It's a bit cumbersome, but has the advantage of being fairly common usage. I have no idea how it would translate to non-English languages. I'm not sure if this is an improvement of the tool call. Don't get me wrong, but your suggestion covers only tool menu and is not very generic. This section should show the user how he uses the tool or start the dialog. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Costs estimates
On Mon, Feb 23, 2004 at 03:42:19PM +0100, Dave Neary wrote: Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? Also, could you mention whether you will need some money in advance to pay for a plane ticket or something? If we know that you need money in advance, we can try and work something out. Well, I don't know if it is possible for me to come, because I'm in Rotterdam to complete my internship in this time. I think, that this isn't the biggest problem for me, rather then the expenses for travel. Your expenses should cover transport and accommodation, and you should also say how much you really need - so for example, My plane ticket is 350 EUR, and hotel will be about 150 EUR for the 3 nights, so that makes 500 EUR, but I guess I could get there with 300 EUR and put up the other 200 EUR myself. Basically, the chances are that there will not be enough money to cover all expenses, but if there aren't we'll try to cover the minimum to have the maximum amount of people there. I checked at opodo.de for travelcosts by plane to kristiansand and it was very expensive: 700 EUR and more (the route is stupid - they'll fly through europe to oslo). The Deutsche Bahn couldn't give me a price, so maybe there will be other chances or places to look for a more cheaper ticket. Please let me know, if there are cheaper ways ... I found some hotels to stay and there are about 764 NOK (about 87 EUR) times 3 and i got: 261 EUR for accomondation. Maybe its possible to stay as a student in the student flats or in a motel room ... If that is, what it looks like (more than 1000 EUR) i better stay in rotterdam for this year and let some more important persons for gimp development to meet eachother in kristiansand. About 500 EUR looks possible for me, but traveling by car seems more stressfull for my car than for me ;) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] ANNOUNCE: GIMP 2.0 User Manual -- developer snapshot
Hi all, the first snapshot of the newly written GIMP 2.0 User Manual is available for download from: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.1.tar.gz and includes help written in English, French, Swedish and German. This developer snapshot is basically for soliciting new contributors, who will assist us in writing and correcting errors. Check out the project page on the GIMP Wiki at: http://wiki.gimp.org/gimp/GimpDocs The Manual itself is written in XML and Docbook. For new doc-writers, knowledge of XML and Docbook is helpful, but not required. Thanks to all who made this snapshot possible. Happy writing and testing, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Project structure
On Tue, Mar 09, 2004 at 09:29:02AM +0100, Dave Neary wrote: I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Help: Roman Joost If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] the GIMP help system, i18n and other problems
Sorry, my mta was a bit messed up lately, so the most of this was discussed before i got it. On Fri, Mar 12, 2004 at 01:59:16PM +0100, Sven Neumann wrote: Hi, (b) Extend the gimp-help.xml format to allow to specify a fallback URL that should be used when no other mapping is given. We will go for the (b) here. I'm fine with that. Adding an url for every id looks for me to much work. (2) How do we handle internationalisation? This isn't completely clear yet. I'll list the open issues: [... details] These are all rather small changes that are easy to implement but we should better do them now. So if there's consensus on this, I would like to see this being implemented over the weekend. Well, only i can do is agree with the proposals and discussions. There is nothing what i can add here. Thanks for implementing this for 2.0 release! Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Press pack
On Mon, Mar 15, 2004 at 05:26:34PM +0100, Dave Neary wrote:
So, over the weekend I did some work on the press pack, mainly re-wording
some thing in the article (there are some things I removed too) to get to a
4 page article. The article, with screenshots, is online at
http://scrappy.ath.cx/~bolsh/ - the article itself is in presspack.pdf
(1.1MB), the latex input file is in presspack.tex, and the screenshots for
the article are in that directory too. To re-generate the article, you'll
need a recent tex latex version (I made it with RedHat 8), and you'll
need to convert the pngs to epss - I did this with
for i in *.png; do
convert $i ${i}.eps
done
May I suggest, that 'pdflatex presspack.tex' will do the job very
quickly without converting the png's into eps files.
So - there we go. Any reccommendations before 2.0 should go here, or to the
wiki.
I looked at the article and sometimes browsed the wiki pages as well.
Good work!
Greetings
--
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
[Gimp-developer] Gimp usability tests
Well, i think first a bit to the background of upcoming Usability Tests.
I met Ellen Reitmayr at the GIMP 2.0 Release Party in Berlin and she is
involved in some Usability studies for the KDE Project (with the whole
company relevantive AG). After some discussions about the KDE Usability
tests, we agreed, that some Usability tests for the GIMP would be nice
for having feedback to the developers from some usability experts.
I met Ellen again and we put some tasks for people who are new to
the GIMP and poeple who consider to change from photoshp to the GIMP.
Ellen wrote the draft that you'll find below. It's considered as a
basis for comments and suggestions to improve the usability of the GIMP
interface. It should not test the functionality itself and issues
already known as bugs. The test should be as effective as possible with
the 4 users and the mostly common tasks.
The first test consists of 4 persons and deals only the 'all-day-use'
with the Gimp (what is the handling of the application like, how good
can one achieve a task etc.). Later, we want to conduct a more extensive
test that will also consider the users' understanding of the common
concepts, such as layers, paths etc. - and how the new user could be
helped to learn these basic concepts (that would be nice to know for the
gimp-help-2 module to get the manual as effective as possible for
helping the user).
The GIMP is the SuSE package of the GIMP 2.0 with the german language
enabled.
Tasks for the first test (all-day-usage; all of the are common tasks for
all people, except the one where the indicated group is mentioned):
1. Create a rectangular selection and subtract the edge of the created
selection.
a) Were the necessary modes found?
b) Does the user select the modi in the right sequence to achieve the
goal. ('Replace a current selection', then use 'Subtract from the
current selection')
c) Does the user know, that the starting point of the subtract selection
has to be placed outside of the current selection and not inside the
selection itself.
2. Create a selection with fixed width and height and a fixed aspect
ratio.
a) Does the user find the right input field.
b) Does the user understand 'Fixed Aspect Ratio' or the german label:
'festes Seitenverhaeltnis'.
3. Selection by color, fill an area with a pattern and cancel the
selection.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user know how to fill the area with the patterns?
c) How to cancel a currently activated selection?
4. Measure how long a distance between some image objects is.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user find the value directly?
c) Where does the user look for the value? At the statusbar or at the
info window?
5. Clone an image object with the clone tool.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user understand how to indicate the starting point for the
clone tool?
c) Does the user choose the right brush from the brush browser?
6. Transform image objects.
The photoshop user should create a layer and shear it with a value for
XX pixels.
The new user should only shear the whole image.
a) Does the user find the right tool in the toolbox or in the menu?
b) Is the user able to use the grid for shearing?
7. Use the color picker to get the color info with sample merged
enabled.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user know why the color which is shown in the image window
is not the same which the color picker gets from the layer?
c) Does he know how to find the checkbox to enable the 'Sample Merged'
function?
8. Using the undo history.
a) Does the user find the journal directly?
b) Does the user understand, how to undo single steps?
9. Add an image grid and change the distance of the grid points.
a) Does the user find the image grid function?
b) Does the user find the image grid preferences in the preferences
dialog?
c) Does the user find the correct option for changing grid preferences?
10. This task is only for photoshop professionals. They should use the
path tool to create a cloud and stroke it with some patterns.
a) Does the user find the path tool?
b) Does he know how to use the path tool?
c) Does he know how to stroke the created path with a pattern?
11. Try to dock some tabs into the docks.
a) Does the user understand that only tabs can be moved betweend docks
and not the docks itself.
b) Does the user find the active area, where he can drop the tab to the
dock.
Thats all of them. In hope it would be useful,
Greetings
--
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: [Gimp-developer] Gimp usability tests
On Tue, Apr 06, 2004 at 11:41:42AM +0200, Dave Neary wrote: If I understood correctly, the objective of this exercise is to see if people find the tool options, understand the icons, and understand what the changing cursor means. Yes - thats the main objective of the tests :) Greetings -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Gimp usability tests
On Thu, Apr 08, 2004 at 08:03:57AM -0700, Carol Spears wrote: On Thu, Apr 08, 2004 at 04:19:33PM +0200, Ellen Reitmayr wrote: I think it would also be interesting to see how more experienced GIMP users handle the software - but for an initial feedback new users are more revealing. We are not trying to make the GIMP run on a field it was never meant for - except you think it was never meant to be used by new user 8-) i had a heck of a time learning computer graphics. another problem with this test is that a seasoned photoshop user would not even think to use tools and methods that are what makes TheGIMP what it is. Why not? I have spoken to some photoshop users and they're very well encouraged to use TheGimp. If a user don't really want to use a software, he could find a disadvantage on every software he see. i am sorry. i am really not being combative on purpose. it has been several years for me of watching the gimp develop to work on several operating systems and race apps that dont even work on linux. some how, some day, some one will think about the linux people also -- so let me keep pointing out how much the tests are very very uneven and actually sort of rude. I don't think they're sort of rude or I miss some point here. Why they're sort of rude, because of some crappy tools which Linux doesn't have? I would expect, that TheGimp will become more powerfull and usable as he was in the past. Thats why the usability tests are for. At least that TheGimp's userbase consists of developers, graphic geeks and normal users. We're providing the Gimp manual for the most of the normal users, btw. can someone please make a fair test, just once? What will be a fair test in your mind? Greetings -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Re: [Gimp-web] Gimp Help on web page?
On Tue, Apr 13, 2004 at 07:04:46PM +0200, Sven Neumann wrote: For the online help, we could consider to use something more advanced than just the HTML version. The wikipedia people are working on a project that allows to convert Wiki content (from MediaWiki, the Wikipedia Wiki engine) to Docbook. This would allow users to edit the help pages they reach when pressing F1. Could be an interesting experiment... I tried a way to have such a thing for our wiki but failed. So, it would be nice to try the approach from the wikipedia guys :) Greetings -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Web content for GUADEC
On Wed, Apr 28, 2004 at 11:05:11AM +0200, Dave Neary wrote: I was thinking, in brief, that we should present a summary of the GIMP people giving talks, as well as a quick About the GIMP paragraph and some screenshots. Also some information about what we plan to do at the conference. How does this sound? If this sounds OK, can I ask people to start collecting that information? Who's up for it? Sounds OK for me, why don't use the WIKI for site preperations (at least to collect the needed informations). Greetings -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Who's coming to GIMPCon?
On Fri, Jun 04, 2004 at 01:22:13PM +0200, Dave Neary wrote: Hi all, A number of people have suggested that a list of attendees who have confirmed they're going would be useful - so could anyone who plans to be there reply to the lists saying so, please? Don't forget to register at http://2004.guadec.org/register/ and request free accommodation if you need it - there's floorspace for all, for a groovy atmosphere. I'll come. If someone registered for the student flats and received a reply from the GUADEC organisation, let me know. I still didn't received anything. After asking in may, they said, they'll send the confirmation mails in few days, which didn't happen. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Re: Usability test - Results available
On Fri, Jun 04, 2004 at 02:59:37PM +0200, GSR - FR wrote: [EMAIL PROTECTED] (2004-06-04 at 1337.31 +0200): http://www.relevantive.de/gimp/report/results_usabilitytest_05.04.html - Clearly mark the current layer Or is this a problem of translating the report? No - this seems to be an issue of the default SuSE theme. The tests were made on a SuSE distribution with an installed GIMP 2.0. They're using QT and GTK+ themes together and it seems, that something is broken there. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Confirmation for GUADEC accomodation?
On Thu, Jun 17, 2004 at 04:09:38PM +0300, Tor Lillqvist wrote: Has anybody else received an confirmation after booking a student flat when registering for the conference? I haven't. I did get a confirmation for the conference registration, but on the other hand no charge has showed up on my credit card yet. And no reply to my inqury to the FiloNova address. (The address that the conference registration confirmation was sent from didn't work...) Odd. Before I changed to livin in free floor space, i booked for student flats as well. But the confirmation about beeing registered for the student flat came in here last week. So I think, you'll get the confirmation E-Mail as well in some days. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] [OFFTOPIC] About the Guadec-2004
Hi David! On Thu, Jul 01, 2004 at 10:35:09PM +0200, David Odin wrote: I just wanted to thanks every one who's came to the Guadec-2004 in Kristiansand. It really has been a great time meeting you, and I was kind of proud assisting to our meeting with many of the great names of the Gimp. Same here! For those who wasn't there, I've put some random pictures here: http://dindinx.net/photos/album.php?a=/GUADEC-2004/ Nice fotos! Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] status of gimp-help-2
and then automatically. This idea has some major problem when it comes to different positioning of menus and other things, that i discarded the idea. Well, the guys from Sun gave said, that we should provide screenshots only when they are *really* necessary. Another problem with screenshots are the dependencies to languages. I propose, that we shouldn't make screenshots for every minor function or dialog, but describe the functions or dialogs better. To summarize: I want thank everyone who made this possible. After writing most of the content, the content needs to be reviewed consistently by everyone, especially the developers or people who know the technology background. Users who are testing the manual might be able to give us feedback, when they encounter errors, typos or not the solution they are looking for. I hope, that I'm able to encourage more people to help us and to have a nice user manual for everyone who is using The GIMP. [1] - gimp/app/widgets/gimphelp-ids.h [2] - http://doc-book.sf.net/homepage/ [3] - http://docutils.sourceforge.net/ [4] - http://docutils.sourceforge.net/sandbox/mmgilbe/rst.py [5] - http://www.mono-project.com Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] rearranging ToolboxXtns Menu
Hi Carol, On Tue, Jul 06, 2004 at 08:47:14AM -0700, Carol Spears wrote: the bug report suggests this rearrangement of the Xtns menu (which is a huge mess if you install all of the difference scripting options that the linux gimp has): The New Structure Toolbox/Xtns/: Module Manager DB Browser Plugin Details Unit Editor * Perl -- Browser Console Server * Help -- * Documentation -- * Bookmarks -- Correct me if I'm wrong, but do you refer here to the normal Help which is now in Toolbox/Help? If not, should the help entry only cover documentation for the plugins or what is the help thingy doing there? Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Guadec5 - first meeting
I hope that the summarize of the first meeting on GUADEC 5 isn't to late. -- Topic: GimpCon status - first meeting Present: Sven Neumann (neo), Tor Lillqist (tml), David Odin (dindix), Dave Neary (bolsh), Roman Joost (romanofski), Simon Budig (nomis), Niklas Mattisson (scizzo), Øyvind Kolås (pippin), Larry Lewing (lewing), Kenneth Wimer, Nathan Summers (rockwlrs), Carol Spears (carol), Manish Singh (yosh), Ville Pätsi (drc), Vidar Madsen (vidar), Jakup Steiner (jimmac), Tuomas Kuosmanen (tigert) The GIMP Foundation Dave Neary first purposed to talk about the GIMP Foundation. The problem is, that Daniel Rogers doesn't want to be responsible for the foundation topic anymore. We discussed the pros and cons about having our own GIMP foundation or the GNOME foundation is covering the responsibilities. If we want to have our own GIMP Foundation, the problem is to have at least one person who can work fulltime with the Foundation. Therefore, we discovered two problems: 1. We need to have money to pay one person who is actually in charge of the foundation issues/topics. 2. We need one person, who want to take this burden and can actually deal with bureaucracy and political issues/topic. 3. It would probably be better to pay a fulltime developer instead. We came to the point that we think, that the GNOME Foundation can address these kind of issues and topics very well. That is, why the proposal leads towards continuing to use the GNOME Foundation. The GIMP Website First we discussed the status of the BETA server, which is maintained by yosh. Yosh needs time to solve the outstanding problems. Afterall, we discussed about moving the CVS of the website to BETA or leave it in the GNOME repository. This is up to the gimp webteam to decide, if the repository is going to stay on the gnome CVS server or if it should be moved to BETA. We discussed who is acting like a project leader of the web team. Many discussions were made about which person will take this role. We proposed Niklas Mattisson (scizzo) to be the project leader of the web team, but it's up to the gimp webteam itself to make a final decision. This will be discussed further on the developer mailinglist, to have comments from other developers. Documentation Roman talked about the current status of the gimp documentation project. He informed about the issues the project has currently and how to address them. One issue is the lack of communication between the writers, which the new mailinglist should address. The second problem is the lack of writers, where jimmac proposed, that in the user point of view, hacking XML content is really difficult. We discussed some solutions like having a better gimp help browser, where the user can edit the current content [1]. Another proposal was a XML WIKI roundtrip. In any case, Tuomas pointed out, that having more documentation writers are better than developing new tools or implementing functionality which takes much time. We came to the conclusion to ask the GNOME docwriters for help and Kenneth Wimer from SuSE offered help from the SuSE documentation team. Also, we concluded to have some proof readers, who gets an information mail if something changed which should be proof readed. [1] - Help Mono Project -- Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] A few website ideas
On Sat, Jul 17, 2004 at 01:40:16AM +0200, Niklas Mattisson wrote: New things: * User-FAQ - This needs to be added to the website as soon as possible. I do not think we have problems with questions but problems with how to design the FAQ. Yeah - i collected some questions because i thought about a FAQ in the user manual. The website is the better place, so if you want to have my docbook xmlised FAQ ;) * Documentation - Is needed to provide users and developers with the new documentation, we also need to have the different languages on the website. This should be able to be done by using some sort of script or buildsystem for the documentation. Anyone that has any good ideas about how to do this in a really good way so that we can update it easily? And so that the languages gets updated also? Maybe be able to update language by language also? Yosh want to give me an account and i'll put the documentation frequently on this one. This should solve the problem I guess... Website style: --- * Hidding submenus - The menu is starting to grow and it would be good to make it hide some of the submenus. As soon as you enter the main section of the link you click on, the submenus will appear. This might help a little in improving the view also to where you are in the menu. This idea also gives us a little problem, the menus need to be named in a way that is understandable and straightforward to the user. Example: Documentation '- Tutorials Having Documentation as the main section name is not really telling me that here you can get a lot of different help instead it is telling me that here you will find some cool documentation. But if we name it: Help |- Documentation '- Tutorials It should say that quot;here you can get some helpquot;. Maybe I am wrong, but this is some of the things I am looking at right now. Well.. i would assume that the Help menupoint gives me help if I'm stuck in the website or need some to know what some words mean. I think Documentation is the better main point. You can then specify which documentation you mean: Documentation |- Developer |- User Manual '- Tutorials (or whatever fits better in the left menu) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Good news
One thing we decided at the GimpCon meeting was, we need more people who proof read the manual. In that regard, I suggest we make a little plan, when some people doing proof reading. I think it's a bad idea to say something like: Here is the manual, please keep proof reading, even though it will be updated constantly. I suggest we tell the proof readers, which pages they can proof read. Those pages shouldn't change to much in the future. This applies at least for the toolbox if I remember correctly. The WIKI is up and I added a new table at the bottom of our project page to know which one proof reads which language. Please feel free to add you there, so we know which person to contact to proof read which written content. Another point which we're looking forward to, is some technical help from SuSE. Kenneth Wilmer from SuSE was present at the first GIMP meeting. After GUADEC, Dave and I were spaeking with Kenneth and he forwarded us to other SuSE people. Actually, I'm looking forward to work with the SuSE people, which will speed up the development of the whole manual. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Wording in German: Toolbox
This mail is for translating the Toolbox into German. I wasn't sure how to translate the Toolbox to German for the manual. But please, hold your breath and let me explain why. I was digging a bit around in the net to find out, which word is more used for the Toolbox: Werkzeugfenster or Werkzeugkasten. The most tutorials I found are using Werkzeugkasten, even Sven uses Werkzeugkasten in his book. But Werkzeugfenster is often more used in forums, when people try to describe a problem and they aren't familiar with The GIMP. I spoke to Ellen to find out what she think. She said, that Werkzeugfenster will be more descriptive. Werkzeugkasten is a bit odd, because she have to think first, what I'm refering to. Thats exactly my feeling. If I were a new user, Werkzeugfenster will be a more descriptive word for the Toolbox than Werkzeugkasten. But, maybe I'm totally wrong and other may think of a completly different window/dialog? So, what do you guys think: Werkzeugfenster or Werkzeugkasten? Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Re: [Gimp-docs] Wording in German: Toolbox
On Mon, Jul 26, 2004 at 05:31:28PM +0200, Sven Neumann wrote: Hi, I am sure you already checked the german glossary maintained by the GTP, didn't you? Yep - and there is nothing in there. But i'll post my message as on gimp-i18n as well. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] help docs for tablets
On Tue, Jul 27, 2004 at 08:35:29PM -0400, Philip Lafleur wrote: William Skaggs wrote: Well, the whole point of trying to use material from GUM is to avoid unnecessary rewriting, but if that HOWTO is the best that can be done, then the only conclusion is that using a tablet in Gimp is only possible in Linux and only for adventuresome people with strong computer skills. That may be the case, but I somehow thought that things were a little better. Why not adding a bibliography and pointing to the Linux wacom documentation? Anyway, putting documents to the WIKI which need a big overhaul is a nice idea. I'll have a look at the document. Maybe, we could document only GIMP related topics and delegating basic tablet usage stuff to the Wacom Howto. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] ANNOUNCE: GIMP 2.0 User Manual -- developer snapshot
Hi all, a new snapshot of the newly written GIMP 2.0 User Manual is available from: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.4.tar.gz and includes major improvements for the four current available languages, which are: English, French, Swedish and German. This developer snapshot is basically for soliciting new contributors, who will assist us in writing and correcting errors. Check out the project page on the GIMP Wiki at: http://wiki.gimp.org/gimp/GimpDocs The Manual itself is written in XML and Docbook. For new doc-writers, knowledge of XML and Docbook is helpful, but not required. We're also looking for proof readers. A mostly up-to-date CVS version of the manual can be found at: http://docs.gimp.org/ Thanks to all who made this snapshot possible. Happy writing and testing, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] ANNOUNCE: gimp-help-2 0.5
Hi, after the pre-release of GIMP 2.2 is released, there is also a new development snapshot available of the GIMP user manual You can download this snapshot from ftp.gimp.org: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.5.tar.gz There is also a browsable up to date CVS version online on: http://docs.gimp.org Note, that this snapshot don't include french content, which is requested by our french docwriters. Documentation in this release is available for English, Chinese, German and Swedish. The documentation covers mostly the upcoming GIMP 2.2. It contains besides documentation also technical fixes, which should let us build a PDF version in the future. The Team from Novell/SuSE helped us a lot to fix technical issues. In that regard big thanks to Thomas Schraitle, Kenneth Wimer and David Neary (who is not employed by Novell/SuSE but helped us communicating the whole thing). Contributors: Raymond Ostertag, Julien Hardelin, Cédric Gémy, Sébastien Barre, Niklas Mattison, William Skaggs, Cai Qian, Eric Lamarque, Sven Neumann, Daniel Egger, Roman Joost Happy Gimping, Roman signature.asc Description: Digital signature
[Gimp-developer] how can I edit pages on wiki.gimp.org?
It seems that the GIMP wiki now have some sort of protection against the annoying spammers, which I really appreciate. I'm really thankfull that Michael gardened the Wiki in the last months. However, am I able to get a password to be able to edit the pages again? Thanks and greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] how can I edit pages on wiki.gimp.org?
On Tue, Nov 09, 2004 at 11:51:34AM +0100, Roman Joost wrote: It seems that the GIMP wiki now have some sort of protection against the annoying spammers, which I really appreciate. I'm really thankfull that Michael gardened the Wiki in the last months. However, am I able to get a password to be able to edit the pages again? Allright, already solved. Thanks to Dave. He pointed me to the UserPreferences page. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Judging panel for splashes
On Sun, Dec 05, 2004 at 06:42:10PM +0100, David Neary wrote: I have no objections as long as people are happy with this. I would be a little worried about some splashes not getting a fair whack because they were submitted late, but sure, why not. When do you think it would be fair to call a result? Well, if I understand you correctly, the core developers have to make the decision which splash screen will be in the next gimp release. Apart from that, if a well defined group of gimp contributors can pick their favorits on mukunds page, we have at least some sort of a result: http://www.mukund.org/temp/gimp/judge/scores.php You stated out, that people picked splash screens on earlier times, so I think it would be fair, if Mukund can reset the current choices and everyone votes again. If this all is to complicated from now on and you guys want a splash screen fast, I'm very fine with your solution Dave. I don't have to make the decision which splash screen will be the winner, so I can shut up if you already figured out how to judge :) Dunno what the others think about this ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] ANNOUNCE: gimp-help-2 0.7
Hi, we released a new snapshot (0.7) of the user manual, which is mainly a bugfix snapshot. You can download this snapshot from ftp.gimp.org: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.7.tar.gz There is also a browsable up to date CVS version online on: http://docs.gimp.org We've also released PDF versions of the manual, which are also available at http://docs.gimp.org. Please keep in mind, that the PDF versions are only for testing purposes. Documentation in this release is available for English, French, Chinese, German, Swedish and Czech. This snapshot includes new screenshots for chinese content, fixes for the build system, stylesheets and the content. Thanks for everyone who contributed to this manual. Happy Gimping, Roman -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP at Chemnitzer Linuxtage 2005
I just want to inform you, that The GIMP was nicely demonstrated at the second biggest linux relevant congress in germany. Sebastian Laube, created some nice posters and presented GIMP here very well. I joined him to help answering all the questions from users. They were also interested in reading the GIMP user manual (german and english), which I really appreciate. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp7YEeBatFRy.pgp Description: PGP signature
Re: [Gimp-developer] Survey: Master's thesis about communication in open sourceprojects: We need your help
On Thu, Mar 24, 2005 at 08:24:08PM +0100, Henrik Farre wrote: We are a group of 4 master students at Aalborg University Denmark, who are writing a thesis about communication in open source projects. As an part of this, we are conduction a survey, and we would like _your_ input, it does not matter if you are a user or a developer, we need everybody's input. Nice, are you publishing your thesis somewhere in the web if its done? Would be interesting how the results are. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpOPYUapH7EU.pgp Description: PGP signature
Re: [Gimp-developer] Large donation
On Thu, Apr 21, 2005 at 01:16:02PM +0200, Dave Neary wrote: I just found out from Tim Ney that the GIMP has received a donation of over $5000 from Hiroyuki Ikezoe in Japan. Wohooo - that are great news! Thanks for everyone who donated to the project so far ... Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpK2BlKMI8kR.pgp Description: PGP signature
[Gimp-developer] ANNOUNCE: Gimp User Manual 0.8 released
Hi, the GIMP developers are proud to announce the new version of the GIMP User Manual GIMP (0.8). Please keep in mind that this release is intended for developers and interested users for reading. The release can be downloaded from: ftp://ftp.gimp.org/pub/gimp/help/testing/ For more information about our project and helping us, you can visit our project page at: http://docs.gimp.org The manual includes a lot of improvemnts by our docwriters and contributors: * spelling fixes for almost every translation * Beginning of Italian and Dutch translation * stylesheet fixes: CSS, HTML and DB2LaTeX driver files * XML validity fixes for french and swedish * Makefile overhaul * a new Hacking styleguide contributions from Sven Neumann, Cai Quian, Daniel Egger, Julien Hardelin, Jakub Friedl, Robert van Drunen, Karine Delvare, David Klementa, Xceals, Axel Wernicke, Roman Joost, Øyvind Kolås Thanks and Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp24wIRUxnli.pgp Description: PGP signature
[Gimp-developer] GUADEC 2005-unified documentation system
Hi folks, because most of the GIMPers didn't attend the freeform session about the planed 'unified documentation system', I would inform you what happend at the session. People came from various projects like KDE, GNOME as well as translators. First, we discussed the pros and cons of the current help browser situation. There is the KDE help browser which provides not only KDE documentation, as well as the GNOME documentatation with some trickery. Most agreed, that scrollkeeper isn't the best approach for finding documentation and has some drawbacks (eg. a generated ID), which I don't want to elaborate more here. So, we first dicussed an approach on how to lookup documentation from the help-browsers point of view in the filesystem. KDE uses an extended key set for looking up documentation in '.desktop' files[1]. Every agreed, that using these keys for all help browsers would solve a lot of problems scrollkeeper had. To summarize up: - a desktop file installed in the #XDG_DATA_DIRS/help or a hidden $XDG_DATA_DIR in the home directory of the user will point to the documentation in the filesystem (we also discussed a naming schema which is available at the wiki[2]). The possibility to install documentation in the users home directories provides the opportunity, that users can independendly install additional documentation. The $XDG_DATA_DIR in the users home directory should be indexed by the help browser first, though. - localized versions of the documentation are seperated by folders. The language is determined by the foldername, which should be an ISO code. Each subdirectory should contain an additional desktop file to provide additional information for the help browser. This is currently a bit vague what the desktop files in these subdirs should provide (could be fallbacks urls to other ids or documents) - if no localized version can be found in the subdirectories, a fallback to the 'default' language is considered or at least the default documentation (in whatever language it is written). So, most of the results aren't important for the GIMP documentation system and the help browser. If we can get a bit more precise about the results of the discussion, the only change to our documentation would be the desktop files we have to write. GUADEC was nice, although I haven't had time to attend much of the talks and sessions. It was a pleasure again to meet all the GIMPers and GNOME people. If there are any questions concerning my mail, please let me know :) [1] - http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.4.html#recognized-keys [2] - http://www.freedesktop.org/wiki/Standards_2fhelp_2dsystem Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp6vM6aFZ50Z.pgp Description: PGP signature
Re: [Gimp-developer] Gimp Conference 2006
Hi David! On Sun, Sep 04, 2005 at 08:20:44PM +0200, David Neary wrote: Come to Lyon for the GIMP Conference, 2006! I hope I can make it. I'm really glad that you guys are organizing again a GimpCon :) Hopefully see you in Lyon! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpBF5wY3C1s0.pgp Description: PGP signature
Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software
Hi Edward, thanks for you proposal. On Tue, Sep 27, 2005 at 01:36:45PM -0400, Edward H. Trager wrote: To see the full proposal, please see: http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ The rest of this email provides a synopsis of the proposal. Speaking as a user here, I'm not sure if your proposal of a drop down is really what solves the problem here. I really like the fact, that the fonts are categorized. That is something which I really miss in the font selection dialogs currently. If a user has installed a motherload of fonts, he mostly has to scroll and scroll and scroll to pick a font. Using a drop down widget has the disadvantage, that I still have to scroll like mad to pick a font, even if they are categorized. I'm able to find the font much faster, but picking a font is cumbersome as it is now. In fact, the only dialog which I endore is the font dialog from Apples Mac OS X. You still have to scroll to pick a font, if there are lots of fonts in one category, but it minimizes the effort. Well, just my 2 cents to your proposal :) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp7DqfMmwmPB.pgp Description: PGP signature
[Gimp-developer] GIMP at LinuxTag 2006?
Hi there, I met Wolfgang Drotschmann from the LinuxTag e.V. at the Chemnitzer LinuxTage last weekend. He kindly asked, if the developers or users of the GIMP want to present the project at the upcoming LinuxTag in Wiesbaden. The LinuxTag will help us of providing chairs, tables, beamer etc. So, is there somebody who wants to volunteer for this (incl. planning and communicating with the LinuxTag e.V.)? Wolfgang gave me an e-mail address where we still can announce our project and also request for help: [EMAIL PROTECTED] I would volunteer, but unfortunately I'm not in Germany at this time, so I'm not able to drive to Wiesbaden. Sebastian Laube, an enthusiastic GIMP user (who also helped to answer lots of user questions at the Chemnitzer LinuxTage) would like to help in Wiesbaden. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpbSoFQIMhXS.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at LinuxTag 2006?
On Wed, Mar 08, 2006 at 01:05:42AM -0800, Carol Spears wrote: On Wed, Mar 08, 2006 at 10:32:45AM +0100, Roman Joost wrote: I met Wolfgang Drotschmann from the LinuxTag e.V. at the Chemnitzer LinuxTage last weekend. He kindly asked, if the developers or users of the GIMP want to present the project at the upcoming LinuxTag in Wiesbaden. The LinuxTag will help us of providing chairs, tables, beamer etc. question what is a beamer? Ow - heh sorry. I ment a video projector. Funny word which sounds English, but it isn't. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpv36om583Vg.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'
On Wed, Mar 22, 2006 at 12:37:52AM +0100, Axel Wernicke wrote: Exactly. So, do you have some Inkscape-like GUI on your mind? well I know this is insane, but I have Mac OS X in mind, where the menu is sticked to a menubar that is always located at the top of the screen :) And even that is not very usable today. I spoke with Ellen Reitmayr about that and she told me that this methology isn't the best (Ellen - correct me if I'm wrong here) I mean... it seems to be so easy to put a fixed menubar at the top of the screen. Users can place the mouse faster to a top aligned menubar than on floating ones. But if you have a lot of windows open, it's getting worse. For example, I always trap into the problem, that the menubar of Mozilla Firefox isn't raise after the browser is started. You've to click in the main window to raise it. I think not copying from Apple nor from Photoshop will be a good start ;) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpUqBwKv8uW8.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'
On Wed, Mar 22, 2006 at 08:20:51PM -0500, Brendan wrote: Please, oh Lord, someone fork Gimp. Actually, I doubt that forking the codebase and starting a new project will solve the problems we're facing. Starting new projects is always easier than manage them, as well as facing problems and solving them. It would make sens if the project comes to a nearly dead end. But this is not the case. Be patient and/or join the development would be much smarter, in my opinion. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpGPeRjDoVBk.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp User Manual 0.10 released
Hi! After more than six months of work, the documentation team is proud to announce a new release of the user manual for GIMP 2.2. This release features a lot of improvements, in particular: * Spelling and grammar fixes for Czech, German, Dutch, Italian, English, Chinese and French * Restructuring of the manual into three parts: Introduction, Concepts and Tutorials, Reference * New language: Croatian * Technical fixes: Makefile updates, better images for the PDF version, CSS updates, new scripts for editing and validating the XML files * New GIMP Keys reference * New content in: o Filters, Menus for German o Tools, Dialogs for Italian o Filters for French, English o Concepts for Dutch * A lot of Bugfixes You can download gimp-help-2-0.10 from: ftp://ftp.gimp.org/pub/gimp/help/ Please keep in mind, that this release includes only the *DocBook/XML sources*. We will provide prebuilt HTML tarballs as soon as possible. The manual is written in DocBook/XML. Please help us to improve it and to fix grammar and spelling errors. Every contributor who wants to help us by providing DocBook/XML patches or just proof reads the manual is very welcome. You can find our new project page at: http://docs.gimp.org Contributions from: Axel Wernicke, Daniel Egger, Hans de Jonge, Tobias Jakobs, Julien Hardelin, Raphaël Quinet, Markus Reinhardt, Raoul Keller, Marco Marega, Cai Qian, Thomas Lotze, Joao S. O. Bueno Calligaris, Semka Kuloviæ-Debals, Calum Mackay, Jakub Friedl, Alessandro Falappa, Marco Ciampa Thanks and Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpay71ZJ8zof.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
Hi folks, On Tue, Aug 29, 2006 at 12:30:59PM +0300, Shlomi Fish wrote: I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. Carol told me she tried to make it look like the Layers dialog. Well, that's not what I'd like to see there, and even so with some CSS and images it can look much better. In any case, a web page can be even more visually appealing without trying to emulate a GUI dialog. Besides the technical problems, I think you should propose a new site layout than just pestering about the current layout. I think 'ugly' is a very subjective term and if no one comes up with something better I wouldn't change anything in Carols position. This is similar to what GIMP users nag the developers about (Usability, Window Management, etc) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpoyquJZLWnt.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp User Manual 0.11 released
Hi! After more than eight months of work, the documentation team is proud to announce a new release of the user manual for GIMP 2.2. This release features a lot of improvements, in particular: * Spelling and grammar fixes for German, French, Italian, Czech and Dutch * New language: Korean, Norwegian and Russian * Technical fixes: Support for the new table of contents view in the help browser that ships with recent development versions of GIMP * New content for German, Spanish, Russian, Czech and French * Lots of bug fixes You can download gimp-help-2-0.11 from: ftp://ftp.gimp.org/pub/gimp/help/ The manual is written in DocBook/XML. Please help us to improve it and to fix grammar and spelling errors. Every contributor who wants to help us by providing DocBook/XML patches or just proof reads the manual is very welcome. You can find our new project page at: http://docs.gimp.org Thanks to the contributions from Nickolay V. Shmyrev, Julien Hardelin, Sven Neumann, Manuel Quiñones, Marco Ciampa, Ulf-D. Ehlert, Michael Natterer, Pierre Perrier, Anne Schneider, Jakub Friedl, Alessandro Falappa, Axel Wernicke, Mr. Dust, Hans de Jonge, Kolbjørn Stuestøl, Jan Smith, Adolf Gerold, Thomas Güttler, Oleg Fritz, Raymon Van Wanrooij, Sally C. Barry, Vitaly Lomov, Stephen Brown, Roxana Chernogolova, Alexandre Prokoudine Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpYlQFy5L4xz.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Minutes from LGM
Hi folks, I just finished to put the minutes up on our wiki from our meetings at the LGM: http://wiki.gimp.org/gimp/LibreGraphicsMeeting Before adding them to developer.gimp.org I'd like to invite some of our native speakers to have a look for spelling and grammar errors. Additionally, I think there are some parts of the minutes which are very misunderstanding to people who were not at our meeting. So please, if you've some minutes, read the minutes ;) If you're able to edit the content, fix confusing paragraphs otherwise feel free to ask questions on this mailinglist. Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpQRB9IirpO9.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp User Manual 2.4.1 released
Hi! A new release of the user manual is available: * new translations: Lithuanian, Polish * new content, spelling and grammar fixes for German, French, Italian, Norwegian, Korean, Spanish, Russian, English * updated quick reference translations: German, English, French, Russian, Swedish, Italian The source files of gimp-help-2.4.1 can be downloaded from ftp://ftp.gimp.org. You will notice that the tarball is a lot smaller than the previous releases as we optimized the screen-shots. Users should wait until this release has been packaged in a pre-compiled form for their platform. Find more information about our goals and how you can help at http://docs.gimp.org. Thanks to everyone who contributed, esp.: Slava, Mickaël Schoentgen, Peter Volkov, Julien Hardelin, Ignacio AntI, Ulf-D. Ehlert, Axel Wernicke, Marco Ciampa, Kolbjørn Stuestøl, Vitaly Lomov, Alessandro Falappa, Sven Neumann, Patrycja Stawiarska, Jean-Pierre Litzler, Pierre Perrier, Roman Joost, Žygimantas Beručka, Mr. Dust, Raphaël Quinet, Harald Duvenbeck, Luigi Chiesa, Yevgeniy Solomovskiy, Jan Herrmann Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Menus under Help/User Manual
Hi, I was about going through the pointers we added to the interesting topics of the manual. Those links like Basic Concepts were added to the menu to help users reading about things they might need to start when using GIMP. The manual has a few more interesting topics where I'd like to add links to. So I've two questions: Since it's a script-fu script, I'd like to know if that is going to be migrated to an XML menu file? Unfortunately the menu is ordered alphabetically, which for the translated version looks kind of messed up. At first putting numbers in front on the menu entries came to my mind, which seems like a bad workaround on another thought. Is it possible to have some kind of ordering. Though probably problematic if it should stay the same with all the translations of the menu. Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP metadata plug-in
Hi, I'd like to hack on the metadata browser (plug-ins/metadata). I'm currently trying to get an overview of the plug-in. The README file provides valuable facts about what's currently implemented. A lot of code is currently commented out. Is there anyone who can give me valuable pointers? I try to come up with something usable ... Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] metadata and JPEG - plans and current status
Hi Raphaël, On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote: Since Roman has offered to improve the metadata handling in GIMP, Sven asked me to document what my plans were for the metadata editor and the JPEG plug-in. Well, these plans are best summarized in the mail that I sent last year: [...] plans Maybe a few points from the first message (2.6 roadmap) should be clarified a bit. In that message, I wrote: [...] Thanks for clearing this up a bit. This makes the metadata browser far more complex than I intentionally thought. [...] Currently, the metadata tree is only available inside the metadata editor, which is implemented as a plug-in. This results in several round-trips via the PDB whenever something must be updated. For example, assuming that Exif would now be handled correctly, the current implementation would lead to the following scenario when a JPEG image is saved: [...] tremendous amount of calls And here is what would happen if the metadata tree could be managed by the GIMP core, but we still assume that the conversion to/from Exif is done by an external plug-in: [...] less tremendous amount of calls Furthermore, here is what would happen if the metadata tree could be managed by the GIMP core and some common metadata operations (such as the conversion to/from Exif) would be in a libgimp-metadata library linked directly with the file plug-ins that need it: [...] less, less amount of calls Sorry for the long details, but using an example like this is probably the best way to explain why it would make sense to have some parts of the metadata handling performed by a library, and why it would be better if the metadata tree could be managed by the GIMP core instead of being constantly converted to/from XMP and stored in a parasite. In my unexperienced point of view, it looks like this should be clarified first, before I try to improve the current metadata editor. IMHO your last point seems to be the way to go, all other attempts like the first one seems to be totally inefficient and error-prune. In my message from last year, I also wrote: + convert EXIF to XMP + convert XMP to EXIF The initial goal of the code that I started writing (and never finished) for the conversion to/from Exif was to get rid of the dependency on libexif. That library had caused several severe stability problems in the past and most developers (including myself) wanted to replace it by some code that was more stable. [...] So contrary to what I originally planned, I think that the code for converting to/from Exif should be based on that library. This will also make our code smaller and easier to maintain. My current plan was to provide a read-only view of the currently stored metadata inkl. a button to update the view. This included the conversion from Exif to XMP. Currently from my point of view - correct me if I'm wrong - the conversation will be called from the imagefile plugin (e.g. jpeg-load), after the Exif data is attached as a parasite. The metadata exif-decode procedure will convert the Exif data to XMP than, to be able to display it as XMP data in the metadata browser. Now after the pros and cons about handling metadata is clarified by your mail, how different do we set our priorities to move forward for this editor and the metadata management? I think we should setup a roadmap first, setup tasks afterwards and start implementing them. Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp User Manual 2.4.2 released
Hi! A new release of the user manual for GIMP 2.4 is available: * Quickreference translations and improvements: Italian, Swedish, Norwegian, Russian * Spelling fixes new content for: German, French, Italian, Norwegian, Korean, Russian, English The source files of gimp-help-2.4.2 can be downloaded from ftp://ftp.gimp.org. Like the previous release, we optimized the screen-shots to get a much smaller release tarball. Note though, that this release is the last user manual release for GIMP 2.4. The next planned release will contain documentation for GIMP 2.6. Users should wait until this release has been packaged in a pre-compiled form for their platform. Find more information about our goals and how you can help at http://docs.gimp.org. Thanks to everyone who contributed, esp.: Andreas Dvorak, Peter Sikking, Roman Frołow, Данил Ильиных, Kasper Hviid, Julien Hardelin, Marco Ciampa, Jean-Pierre Litzler, Mr. Dust, Ulf-D. Ehlert, Alessandro Falappa, Kolbjørn Stuestøl, Vitaly Lomov, Alexandre Prokoudine, Axel Wernicke, Daniel Nylander, Žygimantas Beručka, Liam Quin, Bruce Cowan, Delphine Ménard Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request to include Gimp Manual Book at Gimp.org books (Gimp merchandise)
Hi Monica, On Wed, Oct 22, 2008 at 08:29:41AM +0200, Sven Neumann wrote: Yes, it is a pdf formatted version of http://docs.gimp.org . I wonder what you did? The PDF versions we published on http://docs.gimp.org were still considered as work-in-progress. Additionally they are very much outdated. We formatted the gnu-labeled PDF version for book printing and designed this cover. All pages are completed including all gnu informations. GNU Image Manipulation Program December 2, 2007 REVISION HISTORY $Revision: 2129 $ 2007-07-15 romanofski It's a somewhat unprofessional approach to print and sell the user manual without getting in contact with the authors beforehand, isn't it? And then you put Susan A. Jones as the author. Who is that? I don't remember having seen that name among the contributors to the GIMP user manual. I have to agree with Sven here. The manual was written by a lot of authors and people who spend their free time on the manual. I can't remember that you gave either me or someone else of the documentation team a note that you published the book. It would have been much better to post a mail to the docs mailing list: http://www.gimp.org/mail_lists.html -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Request to include Gimp Manual Book at Gimp.org books (Gimp merchandise)
Hi Monica, We would like to support gimp with donating a part of the revenue. I hoped and I hope that this would be in everybody's interest. Anyway that we could get that back on track? I propose the following: 1. Stop selling this version of the book. 2. Subscribe to the docs mailing list: https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-docs/ so we can discuss publishing a manual including the authors and contributors. If you can't stop selling this version, update it and put the authors of the manual on the front of the book: http://docs.gimp.org/en/pr01.html#gimp-team I don't know who Susan A. Jones is and I also can't think of any contributions from her. Therefore I don't think she should appear as the editor of the manual. Though she probable have to be credited for her task - whatever that was. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request to include Gimp Manual Book at Gimp.org books (Gimp merchandise)
Hi Monica, Did I missed something about GNU? I studied the gimp website, all GNU licences written in the manual, the GNU site etc. We included all pages of the manual within the book, including all GNU infomations, all author names etc. plus the informations that there is an updated html onlie manual available at gimp.org I did not see any hint anywhere that we have to ask for approval of a Gimp doc team and just found out how to contact gimp developers to ask for adding the book. There is actually nothing illegal printing and selling the copies of the PDF version. Although it's not best practice. PDF versions published on docs.gimp.org are not final versions, they're 'snapshot' versions meaning that they include all small an major glitches (spelling errors, layout problems, etc). So with all the glitches in the PDF version and including that it's outdated, I don't think your customers will be satisfied all in all. That could also mean that people think, we as in the contributors to the manual, published our manual on our own through you, which is not the case. I don't want to be offensive but is Gimp and the Gimp manual GNU or not? It is GNU. The manual is not published under GPL it is published under GFDL. Although I noticed later on that somewhere it's written somewhere that the gimp doc team could be contacted to ask if there is any updated version. As a publishing company has to mention one main author we used Susan A. Jones as a editor pen name of the book. Technically there is no way to use 20 or what authors as authors when you publish a book. But all authors are credited in the book pages itself. I do think that is possible ... at least technically. So finally - you can publish the PDF versions of the manual whereever you want to as long as you stick to the license (naming Susan A. Jones as an editor violates the license probably.). But by publishing it without asking you can't expecting any help from us. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-docs] Request to include Gimp Manual
Hi Monica, all in all to settle things down a bit. On Wed, Oct 22, 2008 at 11:19:28PM -0300, Monica Kraenzle wrote: We have just submitted an updated, more accurate product description to Amazon which should appear live soon: Thanks for doing this. Though, after all I wonder if the book is still published and available through Amazon. The URL http://gimpmanual.weebly.com is down and it looks like the published book is gone. So... what's the status now? Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] stuck with the metadata plugin
Hi list,
I initially sent this mail to Raphaël, who seems to be away of some
kind. I think there are a lot of extraordinary C programmers on the list
so I give it a try:
-
I'm still working on the metadata browser. Though haven't gone very
far, also because I can't spend much time in this. The manual drains
more time than I thought.
Anyways - I hope you can help me in a (hopefully) simple question. If
you don't have time currently and think the question is better be
answered on the developer mailing list, let me know.
I'm currently just trying to store the EXIF metadata in the XMP block
during load of a JPEG file.
The weird thing just happens during the few steps:
1. loading the JPEG
2. call:
jpeg-load.c: L 330
gimp_metadata_store_exif (image_ID, exif_data);
3. call:
gimpexif.c: L 70
return_vals = gimp_run_procedure (plug-in-metadata-decode-exif,
nreturn_vals,
GIMP_PDB_IMAGE, image_ID,
GIMP_PDB_INT32,
exif_data-size,
GIMP_PDB_INT8ARRAY, exif_data,
GIMP_PDB_END);
4. call:
metadata.c: L 454
data = (ExifData *) param[2].data.d_int8array;
exif_data_size = param[1].data.d_int32;
if (! xmp_merge_from_exifbuffer (xmp_model,
data,
exif_data_size,
error))
5. call:
exif-decode.c: L 5
if (data-size)
exif_iter_content (xmp_model, data);
6. call:
exif-decode.c: L 104
for (i=0; i EXIF_IFD_COUNT; i++)
{
content = data-ifd[i]; /* BANG! */
At this point, I'm iterating over the exif content and entries. When I
try to access the entries I'm getting a Segmentation fault *Bang*.
A segmentation fault also happens if I'm trying to access the EXIF
entries at the point in the metadata.c file. So I'm just guessing that I
missed something but I don't have any clue what ...
I created a patch against the current TRUNK with my changes and put it
on:
http://amy.gocept.com/~roman/metadata.patch
It's not productive code, just my lousy attempt to get more the EXIF
content displayed in the metadata browser ;) And of course more
experience with C.
Thanks for any helpful ideas
--
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's next for the meta-data browser
On Thu, Jul 02, 2009 at 09:58:33PM +0200, Sven Neumann wrote: Two questions: 1. Do I have to be careful when entry callbacks write to the XMPModel (or any other model or structure) everytime a user types in a character (performance wise)? Usually this is not a problem. But if it turns out to be one (because changing the model is expensive), then you might want to delay changes to the model. You can do that for example by not connecting to 'changed' but instead apply the changes when the dialog is closed. Or you could connect to 'activate' and 'leave-notify-event' and apply the change when the user presses Enter and when the focus leaves the entry. 2. I tried to find out how I can add callbacks to editable tree items. Those callbacks should update the corresponding fields in the description tab. E.g someone changes in the advanced tab the title field. This change should then visible in the description tab and the title has changed. What am I looking for, when I want to add callbacks to those tree columns? A pointer to documentation or some keywords I should look out for would be helpful. You want to connect to the 'edited' signal of the GtkCellRendererText object that is responsible for rendering the editable cell. Cheers for that response! Helped a lot! Greetings, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] where to put widgets for plugins
Hi, I wonder where I can put and compile a widget I've written for the metadata browser. It's a GtkEntry widget which is linked to the XMPModel. The entry takes three parameters in the constructor, the property, the schema and the XMPModel as a data type. If I put the widget into libgimpwidgets, I probably have to link it against the xmp_model which is defined in a plug-in. If I leave the widget in my metadata plug-in, I need to change the Makefile to use the widget. Any trials I've done so far were not successful. Maybe the widget should be more general. Because the XMPModel is storing the data in a GtkTreeModel, the widget could be initialized with a GtkTreeModel, rather providing the whole XMPModel. I'm a bit clueless here what the best solution would be. Cheers for any suggestions, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] where to put widgets for plugins
On Sat, Jul 11, 2009 at 08:33:11AM +0200, Martin Nordholts wrote: On 07/11/2009 08:23 AM, Roman Joost wrote: Hi, I wonder where I can put and compile a widget I've written for the metadata browser. [...] Since we don't want the libgimpwidgets to depend on the metadata plug-in, you should put the widget along with the metadata plug-in source. That the metadata plug-in will depend on a UI library is not a problem. If we can avoid extending our plug-in API we should do that. Thank you! Not beeing to fuzzy here, but do I need to follow a directory structure? Say, all the widgets - it's currently just one - should be placed into a subdirectory widgets. Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] meta-data browser: EntryWidget + treemodel = chicken/egg problem
Hi folks, I pimped an GtkEntry widget for the metadata editor - thanks to Sven for his help. the problem: The XMP metadata is stored in a treemodel. The metadata browser has currently two notebook panes where the user can enter data: the description tab for title, author, description and the advanced tab which is a view onto that treemodel. If I type in the title in the description tab, the change is reflected in the treemodel therefore also visible in the advanced tab. If I change values in the advanced tab I was not able to e.g. update the title entry widget. my possible solution: My GtkEntry is instantiated with the xmp_model (read treemodel), the schema uri (e.g. http://purl.org/dc/elements/1.1/) and the property name (e.g. title). I subscribe to the 'row-changed' signal of the treemodel (now maybe that's my first mistake), as well as the entry changed signal (maybe another mistake). During initialisation nothing is written to the model and my entry widget is not emitting any signals. When I enter the first characters in the entry, the following happens: 1. the schema is set (row-changed signal is emitted) 2. the property *value* is set (another row-changed signal) That raises actually to a big problem, because when I populate two of my Entry widgets in the browser I get a pingpong going on between the Entries. Funny, but not usable. Is it possible to subscribe to a row-changed event by also using a GtkTreePath as some kind of selector? The problem is, that on instantiation time, I don't have a value set in the treestore, therefore also no path :( Maybe using the treestore as a view (model) as well as a data (model) is another problem here. I also thought about changing the xmp-model to emit custom signals, like a 'property changed' event, which uses the schema_uri and the property as an identifier. I can't really see that solving my problem here though. Additionally, I've read the GtkEntry and GtkCellView source code for any additional information. The GtkCellView is storing the model in a private (need to read what this is about) and a it is using a reference for the row. Maybe that's something I should try... Any help or pointers to documentation or source code would be very much appreciated! Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] meta-data browser: EntryWidget + treemodel = chicken/egg problem
Hi Martin, On Mon, Jul 13, 2009 at 12:02:29PM +0200, Martin Nordholts wrote: On 07/12/2009 03:12 PM, Roman Joost wrote: When I enter the first characters in the entry, the following happens: 1. the schema is set (row-changed signal is emitted) 2. the property *value* is set (another row-changed signal) That raises actually to a big problem, because when I populate two of my Entry widgets in the browser I get a pingpong going on between the Entries. Funny, but not usable. When a listener makes changes to a the thing it listens to, it typically will want to have g_signal_handlers_block_by_func()/g_signal_handlers_unblock_by_func() around the piece of code that does the change, and/or if (new_value == current_value) return; at the beginning of the callback to prevent the pingpong you are describing. Sometimes it's tricky to get this right. Thanks for this hint. I haven't tried it so far, but I looks like I need it if one of my handlers already dealt with the signal successfully. It's actually interesting, that I tried various different ideas on implementing this. When I think I already tried everything, there is another idea popping up which I try. So there is progress :) Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Problem with creating/compiling XMPModel which inherits from GObject
Hi,
I thought it would be handy, if my XMPModel which stores the XMP
metadata could emit it's own signals if properties or schemas change.
The model now inherits from GObject and but most of the data structure
is unchanged:
struct _XMPModel
{
GObject parent_instance;
GtkTreeStore *treestore;
GSList *custom_schemas;
GSList *custom_properties;
XMPSchema*cached_schema;
GtkTreeIter cached_schema_iter;
};
My problem now is, that:
1. to get it some sort to compile is to include header files in my
xmp-model.h header file (gtk.h, glib-object.h, xmp-schemas.h) and I
don't know why.
2. which actually prevents me from working on that more is the
following error:
In file included from /usr/include/glib-2.0/glib/gmacros.h:40,
from /usr/lib/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gtype.h:26,
from /usr/include/glib-2.0/gobject/gboxed.h:26,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
from /usr/include/gtk-2.0/gdk/gdk.h:32,
from /usr/include/gtk-2.0/gtk/gtk.h:32,
from xmp-model.h:25,
from xmp-schemas.c:21:
/usr/lib/gcc/i486-linux-gnu/4.3.3/include/stddef.h:152: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’
I'm just wondering what I'm doing wrong here. If there is more code
needed, I could probably attach it to a bug or put it on the net
somewhere.
Am I mixing some fundamentals of Gtk and GObject programming here?
Cheers,
--
Roman Joost
www: http://www.romanofski.de
email: romanof...@gimp.org
signature.asc
Description: Digital signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with creating/compiling XMPModel which inherits from GObject
On Thu, Jul 16, 2009 at 04:26:41PM +1000, Roman Joost wrote: Hi, I thought it would be handy, if my XMPModel which stores the XMP metadata could emit it's own signals if properties or schemas change. The model now inherits from GObject and but most of the data structure is unchanged: [...] I'm just wondering what I'm doing wrong here. If there is more code needed, I could probably attach it to a bug or put it on the net somewhere. Just in case someone needs to look at the patch: http://amy.gocept.com/~roman/0001-WIP-XMPModel-object-with-custom-signals.patch Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with creating/compiling XMPModel which inherits from GObject
Hi Martin, On Thu, Jul 16, 2009 at 04:27:01PM +0200, Martin Nordholts wrote: The errors are due to that header files are included in the wrong order in the translation units (c files). Moving these around a bit solves your compilation problems, I've attached a patch that should be applied on top of your patch. (You can squash the commits together with an interactive git rebase) Thanks a lot! Awesome! There are alternative ways to attack this problem [...] Thanks a lot. That sounds very reasonable. I think I go for that solution! Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] XMPModel and custom signals
Hi, I wasn't sure if I should bring up this discussion on the mailing list or better on the bug report (http://bugzilla.gnome.org/show_bug.cgi?id=589474). I think it could be useful to subscribe to events emited by the XMPModel (although other people know something I don't know). The old XMPModel used a treestore to store property and schema data. My current work version inherits from GtkTreeStore. There are two things which happen to the treemodel: a property or a schema could be set. If I'm subscribing to the row-changed event only, I have to figure out in my callback what has changed: a property or a schema. By using two different signals, it would be more explicit what was changed. I'm working on another patch, which uses custom entry fields which monitor one property in the XMPModel. Currently they're subscribed to the 'row-changed' event in the XMPModel, which makes it hard to figure out if the change belongs to the Entry or not. If I could subscribe to a 'property-changed' event, I still have to figure out which property has changed, but don't have to figure out *if a property* has been changed. That would make life easier. Now - as I said - maybe I missed something, but I'm keen to learn :) Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
On Thu, Jul 30, 2009 at 10:42:55AM +0200, Martin Nordholts wrote: On 07/28/2009 12:40 PM, Roman Joost wrote: Hi, I wasn't sure if I should bring up this discussion on the mailing list or better on the bug report (http://bugzilla.gnome.org/show_bug.cgi?id=589474). [...] I'm working on another patch, which uses custom entry fields which monitor one property in the XMPModel. Currently they're subscribed to the 'row-changed' event in the XMPModel, which makes it hard to figure out if the change belongs to the Entry or not. If I could subscribe to a 'property-changed' event, I still have to figure out which property has changed, but don't have to figure out *if a property* has been changed. That would make life easier. Just to get a discussion going: Coulnd't you implement your own property-changed and schema-changed in XMPModel? I.e. you would have to write some wrappers on top of row-changed that provides nicer callbacks than row-changed. I could and the patch provided by that bug adds a custom 'property-changed' signal. Sven and Mitch thought, if I inherit from XMPModel, I wouldn't really need the 'property-changed' signal, because I'd be able to control the 'property-changed' signal. That is true, but maybe I wasn't clear enough saying, that I want to distinguish if a schema or a property changed by using different signals. Or I'm missing information ... Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
Hi Martin,
On Sat, Aug 01, 2009 at 09:32:36AM +0200, Martin Nordholts wrote:
On 07/31/2009 07:12 AM, Roman Joost wrote:
I could and the patch provided by that bug adds a custom
'property-changed' signal. Sven and Mitch thought, if I inherit from
XMPModel, I wouldn't really need the 'property-changed' signal, because
I'd be able to control the 'property-changed' signal. That is true, but
maybe I wasn't clear enough saying, that I want to distinguish if a
schema or a property changed by using different signals.
Inheriting XMPModel from GtkTreeStore (that's what you meant, right?)
Yes - that's what I ment. Sorry for the misunderstanding.
does not change the fact that it would be nice to have a
'property-changed' signal as a convenience if you have the need to
listen property changes
So ... I'm just wondering. If I like to use two signals for the
XMPModel, does it still make sense to inherit from GtkTreeStore? I mean,
I can't currently see any benefits if I inherit from GtkTreeStore.
My current model looks like this:
struct _XMPModel
{
GtkTreeStore parent_instance;
GSList *custom_schemas;
GSList *custom_properties;
XMPSchema*cached_schema;
GtkTreeIter cached_schema_iter;
};
The model before inherited from GObject and had another member, which
was the GtkTreeStore.
Cheers,
--
Roman Joost
www: http://www.romanofski.de
email: romanof...@gimp.org
signature.asc
Description: Digital signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
Hi Martin, On Sun, Aug 02, 2009 at 01:58:20PM +0200, Martin Nordholts wrote: On 08/02/2009 01:50 PM, Roman Joost wrote: does not change the fact that it would be nice to have a 'property-changed' signal as a convenience if you have the need to listen property changes So ... I'm just wondering. If I like to use two signals for the XMPModel, does it still make sense to inherit from GtkTreeStore? I mean, I can't currently see any benefits if I inherit from GtkTreeStore. In general, aggregation is preferable to inheritance because the former results in more dynamic code with less assumptions. If you think aggregation makes more sense than inheritance in this case, then I'd say go ahead and use aggregation, i.e. have a GtkTreeStore as an instance member in XMPModel Should I redo the patch posted for the bug I've created at: http://bugzilla.gnome.org/show_bug.cgi?id=589474 and implement the schema change signal (which is missing), or can someone review the patch again? Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
On Mon, Aug 03, 2009 at 09:46:34PM +0200, Sven Neumann wrote: Hi, On Fri, 2009-07-31 at 15:12 +1000, Roman Joost wrote: I could and the patch provided by that bug adds a custom 'property-changed' signal. Sven and Mitch thought, if I inherit from XMPModel, I wouldn't really need the 'property-changed' signal, because I'd be able to control the 'property-changed' signal. That is true, but maybe I wasn't clear enough saying, that I want to distinguish if a schema or a property changed by using different signals. Nothing keeps you from adding more signals to your derived class. You can easily emit more detailed signals from the 'row_changed' handler in your class. What's probably even better than a plain 'property-changed' signal is one that has a detail that identifies the property. Then code can subscribe to 'property-changed' to get notified about any property changes and your entry, which is probably just interested in a special property, let's call it 'foo', would subscribe to 'property-changed::foo'. See http://library.gnome.org/devel/gobject/stable/signal.html#signal-detail for more information on the detail argument. Wow - awesome. That looks very much I'd like to use. I revamp the XMPModel and try to incorporate this for the property-changed signal. Thank you both, Martin and Sven. Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Metadata-Browser and Widgets
Hi folks, I'm back working on the meta-data browser. Current problem I suppose is to overcome my lack of C knowledge towards inheritance. I've implemented a GtkEntry widget which is tied to the XMPModel. This means, a user can change the meta-data title on the description tab and in the advanced tab (showing a tree of currently set meta-data values) and both widgets stay in sync with the value entered. I would like to do something similar for the text views. Take the description as an example. Martin gave me a hint towards inheritance, which I'm currently trying to solve. My understanding so far, if I would inherit from my GtkEntry widget, I wouldn't be able to overwrite my implementation so I can display a GtkTextView. I also thought about inheriting from a more basic widget and somehow use a GtkEntry or GtkTextView as a property. That didn't really worked well either. Now I have a similar implementation working with a GtkTextView as a base class including borrowed code from my GtkEntry. I would like to merge both to something more flexible, but I can't really think of a better architecture. Maybe the clue is to overwrite the constructor which returns either a GtkEntry, a GtkTextView or ...? Any help, pointers, new ideas would be appreciated :) Cheers, -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Calling a function from a custom module
On Sun, Apr 18, 2010 at 11:12:05AM +0200, Jason S. wrote: As general practice, I've written a function that I put inside a file called ofstream.py (placed in the same folder as gimpfu.py), which consists of: [...] example code But I keep getting an 'execution error' linked to the fout statement. Could you paste the error as well? If I comment out that line and replace it with something else, it works fine. The 'import ofstream' line gives me no trouble; its the function call thats the problem. IMHO it's better do use absolute imports like: import ofstream ofstream.fout() But that will not fix your problem. Why am I having this issue? I can use functions located in gimpfu.py just fine (register, main, etc). Why can't I use my own function? It would be much more helpful if you could paste the whole traceback... If you can import your module, it should also be possible to access your function. What will happen if you you explicitly import your function: from ofstrem import fout Cheers -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
