Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On 6 Oct 2001, Daniel Egger wrote: Am Die, 2001-10-02 um 19.14 schrieb 1002042874: there is probably no need for XML as there are no attributes etc. If you use XML for texts like tips or dialogparts then attributes are being used for specifying the language the text is in. We can also use XML for its original purpose -- a markup language. Even just adding an emphasis tag can allow tip writers to be emmuch/em more expressive. But I was thinking of adding the ability to have small graphics in the tip of the day. Am I the only one that finds it odd that GIMP is an emimage manipulation/em program, yet the tips are all in text? Even the database visualization app I worked on over the summer could embed small graphics in the tip of the day, although in that app it was used mostly to display which button does which thing. I think that small graphics could be used to great effects -- to make your graphic look like graphic, use the bumpmap plugin. OK, it would take a little more text than that to make it work well, but you get the idea. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger [EMAIL PROTECTED] writes: If you use XML for texts like tips or dialogparts then attributes are being used for specifying the language the text is in. A tip might look like this: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip DIA for instance uses something alike to implement modular extensions to the graph set. It's a lot more versatile then the header approach with my lovely friend gettext since the information is not spread over several files which need to be generated, compiled and installed. If we had more tips we could even categorize them. I don't think we want all translations in one file. Not in CVS and not in the distribution. The file will get large and akward to edit. I don't think generation, compilation and installation of several files is a problem since there are good tools to do that. Actually using XML would also solve a part of the how do we localise plugins that are not part of the distribution problem and might lead to a leaner core distribution and an intelligent repository which is a really cool thing. Back when we implemented the first round of the now active stuff this techniques were not available for consideration and thus we ended with the kludgy solution. hmm, how would XML help here and what are the kludgy solutions you speak about? Actually I do have some ideas in this area and I think Ingo wanted to outline a plug-in description draft that uses XML. But the use of XML alone will not solve any our problems. After all it's only a markup language and there's nothing really new to it that you couldn't have done years ago. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Nathan C Summers [EMAIL PROTECTED] writes: We can also use XML for its original purpose -- a markup language. Even just adding an emphasis tag can allow tip writers to be emmuch/em more expressive. GTK+-2.0 allows some simple markup to be applied to labels and other text areas without too much hassle. Actually we don't even need to go for the XML file solution, we can simply use the XML-style markup tags in the text, no matter how we store it. Here's the API: http://developer.gnome.org/doc/API/2.0/pango/pangomarkupformat.html But I was thinking of adding the ability to have small graphics in the tip of the day. Am I the only one that finds it odd that GIMP is an emimage manipulation/em program, yet the tips are all in text? Even the database visualization app I worked on over the summer could embed small graphics in the tip of the day, although in that app it was used mostly to display which button does which thing. I think that small graphics could be used to great effects -- to make your graphic look like graphic, use the bumpmap plugin. OK, it would take a little more text than that to make it work well, but you get the idea. perhaps I'm imaging something wrong here, but I think graphics would be overkill for the tips. Stuff like this belongs to the help pages if you ask me. It would probably help to allow links to help pages in the tips dialog and it would also be much simpler to implement than text flow around image boxes (unless you want gimp to depend on gtkhtml2 for the tips). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
perhaps I'm imaging something wrong here, but I think graphics would be overkill for the tips. Stuff like this belongs to the help pages if you ask me. It would probably help to allow links to help pages in the tips dialog and it would also be much simpler to implement than text flow around image boxes (unless you want gimp to depend on gtkhtml2 for the tips). I agree with Sven about images in tips. Maybe in the future, after we (we mainly means syngin) have finished documenting all the stuff that HAS to be documented, it might be nice to add some tutorial-like docs to the help stuff. Then the tips could link to some of that stuff. But I can definitely see a lot of potential in linking tips to the help. That way the tips can be little tidbits that then link into the help to give more information. I don't know that any of the help people have time to make changes like this in the present, but I can see a lot of potential in it for future development. It is nice to leave room for future development. bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 11:23:11AM +0200, Sven Neumann wrote: It's a lot more versatile then the header approach with my lovely friend gettext since the information is not spread over several files which need to be generated, compiled and installed. If we had more tips we could even categorize them. I don't think we want all translations in one file. That wasn't my point. I meant that it might be sensible for tips (instead of introducing the header kludge) and for plugin descriptions because it makes them more versatile and not bound to the distribution. The file will get large and akward to edit. In the mentioned case this is not an issue. The tips are pretty small anyways (just compare it to a uncompiled catalogfile) and for plugins this isn't an issue at all. Actually using XML would also solve a part of the how do we localise plugins that are not part of the distribution problem and might lead to a leaner core distribution and an intelligent repository which is a really cool thing. Back when we implemented the first round of the now active stuff this techniques were not available for consideration and thus we ended with the kludgy solution. hmm, how would XML help here and what are the kludgy solutions you speak about? Remember how we solved the localised-menuentries-for-plugins problem? I'd call it kludgy and it causes trouble for external ones. So how could it look like? Think glade, it uses XML files to describe userinterfaces; if we go this way we'll have two choices: - Create the complete userinterface from XML (including translations). I'd love to see that because it would ease pluginwriting quite a bit if we also had good interfaces to access the layerdata directly by rectangular coordinates also. - Use the file just for the labels and their translation as well as for the menuentries; by using a fast library this might also obsolete pluginrc - simply drop the description in a special directory and you're all set also for scripts. Actually I do have some ideas in this area and I think Ingo wanted to outline a plug-in description draft that uses XML. Cool. I'd like to see it when ready. But the use of XML alone will not solve any our problems. Of course not. After all it's only a markup language and there's nothing really new to it that you couldn't have done years ago. I tend to disagree; although being available for quite some years now the tools to use it are still being heavily develloped and were nearly non- existant back when we last implemented the latest featureset wrt. plugins. Yes, it's only a markup language but the big advantage is that it's a standard and well developped and we should make use of that. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote: We can also use XML for its original purpose -- a markup language. Even just adding an emphasis tag can allow tip writers to be emmuch/em more expressive. That's an abuse of a tag. em is a stylistic tag from the HTML days, with XML text should be marked like: markuplt;em/markup is a stylistic tag. The actual rendering is up to the stylesheets or preferences of the user/developer. But yes: In theory you're right. But I was thinking of adding the ability to have small graphics in the tip of the day. Am I the only one that finds it odd that GIMP is an emimage manipulation/em program, yet the tips are all in text? Even the database visualization app I worked on over the summer could embed small graphics in the tip of the day, although in that app it was used mostly to display which button does which thing. No, I think the tips should be kept rather simple. But what I can imagine is a link to the correct sections in the manual to look up more information on the tip. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, 2001-10-06 at 12:49, Daniel Egger wrote: On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote: We can also use XML for its original purpose -- a markup language. Even just adding an emphasis tag can allow tip writers to be emmuch/em more expressive. That's an abuse of a tag. em is a stylistic tag from the HTML days, with XML text should be marked like: markuplt;em/markup is a stylistic tag. The actual rendering is up to the stylesheets or preferences of the user/developer. But yes: In theory you're right. No prof. You've got it wrong. em means emphasis. It means the text should be given some sort of emphasis. The stylesheets then determine what that emphasis is. (italics, color change, etc.) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On 5 Oct 2001, at 16:06, Carol Spears wrote: Okay, everything I know about XML I learned by osmosis (ie, i slept with XML in a Nutshell under my pillow), but XML seems to make sense and be a lot less rigid than SGML. To the contrary, XML is way more rigid than SGML, that is its defining quality. XML = rigid(SGML). What they did was throw out a whole bunch of features that not many people were using, then tighten the rules. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
Heya Rockwalrus, [EMAIL PROTECTED] (2001-10-06 at 0206.15 -0600): But I was thinking of adding the ability to have small graphics in the tip of the day. Am I the only one that finds it odd that GIMP is an emimage manipulation/em program, yet the tips are all in text? Even the database visualization app I worked on over the summer could embed small graphics in the tip of the day, although in that app it was used mostly to display which button does which thing. I think that small graphics could be used to great effects -- to make your graphic look like graphic, use the bumpmap plug-in. OK, it would take a little more text than that to make it work well, but you get the idea. Didn't Clippy get fired? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 14.33 schrieb 1002371616: That wasn't my point. I meant that it might be sensible for tips (instead of introducing the header kludge) What is 'the header kludge'? I never got that bit. To use gettext on has to have a file with C syntax; the idea is to have a header file where the original messages are defined and then use gettext with that. Plug-ins are a whole different ball game by themselves. There still is no solution for distributing plug-ins apart from the few that will remain in the GIMP core distribution (the plug-in manager thing). Perhaps it is better to discuss plug-in localisation in that context. IF we need to add another dependency it has to be worth it. Solving problems by using XML for everything seems only clever to me. It does not make sense to use XML for tip files while plug-ins still keep in beeing broken (in the localisation context). Someone mentioned how well Dia seemed to be doing in that respect. Well, Dia puts the text strings for a sheet in a different file per sheet. Even with only 8 supported languages, this already looks totally cluttered to me. Really? Everything is were it belongs to and nothing is used within wrong context and, last but not least, its extensible and that even easily. The tips file is 9 kB now. With 15 supported languages (how many on the way?), that would become 135 kB. In contrary to po files untranslated messages are simply nonexistant. And you forget one thing: All .po files together are by definition bigger since the original text is repeated within every single file. We'd need a tool to merge changes, or would CVS be enough? CVS seems fine to me, what would you need a tool for? There's no need to merge catalogtemplates with existing catalogs in XML world. You cannot expect translators to wade through 30 lines of other languages to be able to add his/her own translation (30 lines per string to be translated, that is), so that translators do need to work on separate files. Why not? And where do you get the 30 from? If you have 15 languages then you'll have at maximum 15 times the original text to skip. Beeing a translator myself (and in fact also one of the one of the DIA sheets) I can tell that this is not as evil as it might look. It is just a subset of SGML you know, and not that good at it. There is nothing you can do with XML that you cannot do with SGML. That's correct. Though there are much fewer tools for SGML than for XML; why? Because SGML was and still is too bloated for many uses. XML apps are usually not meant to be read and edited by humans, Huh? so I expect you have got a tool for the translators in mind? If necessary I can hack something up but it should not be necessary. I really don't see the big difference to hacking a .po file. gettext is also a standard. Great. Show me the specs... I'm not talking about de-facto or so called industry-standards. gettext is such a crap that I really doubt there was a standarisation process which led to a proper specification. XML was developed to give marketdroids a new fad to woo, whereas gettext was developed to let translators do their thing. XML was designed to have a standarised markup language to allow human readable, verificable and interchangeable files. Don't follow the hype but choose the best of all worlds and that's where XML chimes in; sure you can use this approach here and the other there but in the end you're just wasting your own time by thinking of new formats and algorithms to parse them. I know which I as a translator prefer. Allright then, I'll keep it in mind. If we tarred the tips directory, would that solve your 'many files' problem? ;-) I don't care about the amount of files in special directories or the final tarball, I care about the number of libraries in /usr/lib and hundreds of files /usr/share/locale/*/LC_MESSAGES though -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 12.51 schrieb 1002365476: No prof. You've got it wrong. em means emphasis. It means the text should be given some sort of emphasis. The stylesheets then determine what that emphasis is. (italics, color change, etc.) No, em is HTMLism. There's no em in DocBook for example, it's emphasis there Though the look of em can be changed by an CSS stylesheet it is not exactly the same as emphasis... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 19.05 schrieb 1002387943: That wasn't my point. I meant that it might be sensible for tips (instead of introducing the header kludge) and for plugin descriptions because it makes them more versatile and not bound to the distribution. I was referring to the tips and nothing but the tips. Me not. I'm always a step ahead. Would you mind telling me why you want to change the tips format, I must have missed that. I disagree. The english tips file has about 180 lines, with XML markup it will grow a little. At the moment there are 26 languages in ALL_LINGUAS. This would mean that the file would grow to over 5000 lines. Do we have translations for all tips in 26 languages? XML don't grow with the number of languages unlike the po-directory. And 5000 lines are still a reasonable number considering that the German catalog for app has more than 6000 lines. To edit your language, you'd most probably have to have two editor views open since you won't be able to get the original tip and your translation on the same page. Please stop exagerating; a person that doesn't have a monitor that is able to display 26 lines at once is pretty poor anyway. A second problem is encodings. There aren't many good UTF-8 capable editors out there and if you have all translations in one file, you can't easily convert to your native encoding for editing. That's a good point. On the other hand we might want to go for UTF-8 though instead of having a whole bunch of different encodings, and then there's still the possibility to escape special characters. As a translator, I'd prefer to have the original version in one file and edit a po file created from that source. If I am informed correctly, this is what most GNOME programs do or plan to do these days and there's a bunch of developer tools available for this purpose in the intltool module in GNOME CVS. Hm, if you really insist on using the xml-i18n-tools that'd be fine for me; it's just a small detail of the whole process. it is not very elegant, but I haven't yet heard one report where it didn't work or caused problems for externals. That said, I wouldn't object to a cleaner solution. It works for now though it was quite some action when we implemented it and it's still not sure it will work in the future; that's a very fragile piece of code. However if you think about the plugin problem that has been discussed every now and then heavily this is the only way to solve it (well, at least no one mentioned a better one as of yet). I don't think we want to force plug-in developers into using glade. Me neither, but something alike would be pretty cool. Since Mitch and you already unified the plugins a quite a nice way this would be the crown to it. :) I'll address the rest of your mail in another email... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
[EMAIL PROTECTED] (2001-10-06 at 1125.23 -0400): Didn't Clippy get fired? Maybe next version should have Wilberpy as helper. The concept image was nice: I see you want to draw a straight line. /me runs GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
Sven, [EMAIL PROTECTED] (2001-10-06 at 1933.28 +0200): Hi, If we really want to use the file in other places (web-sites), someone involved there needs to come up with a proposal for the format. It seems that all any decent site would need would be this: ?xml version=1.0? gimp-tips tip tip-number 0 /tip-number This is the first trip. /tip tip tip-number 1 /tip-number This is the second trip and it has bbold/b text. /tip tip tip-number 2 /tip-number This is the last trip. Now, you are on your own. /tip /gimp-tips Otherwise I'd say that the simple format using the Pango Text Attribute Markup Language directly as outlined above should be good enough. For http://developer.gnome.org/doc/API/2.0/pango/pangomarkupformat.html Should be easy to ignore these tags for web site display. I wish my technician would come back from his European vacation and help me talk about this. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 06:06:19PM +0200, Guillermo S. Romero / Familia Romero wrote: Maybe next version should have Wilberpy as helper. The concept image was nice: I see you want to draw a straight line. Or rather: I see you erase. Let me erase the rest of the image for you, then save. *g* /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 07:33:28PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: have done it before. I can see at least one more advantages of using an external file: The tips don't stay in memory all the time. So we should probably go for it. (just a sidenote: if tips were compiled-in and large enough for this to be relevant, they would still not stay in memory all the time. guess that the parser would take up more memory ;). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
