[libreoffice-users] Setting up Hyperlink in Impress
Hi, I'm using LibreOffice version 4.2.7.2, Build: 4.2.7.2 Arch Linux build-2 I'm trying to set up the color of the visited and unvisited hyperlinks on slides with: Tools Options Appearance Unvisited Links, Visited Links On some slides this works but on some slides dont. Why? - Best Regards from Pál -- View this message in context: http://nabble.documentfoundation.org/Setting-up-Hyperlink-in-Impress-tp4129983.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Re: Comments on pdf file size in 4.4 alpha; and a new bug?
Hi :) Thanks Stuart and Dr Som too :) There were a few tpyos in there so i'm glad it makes enough sense! I just heard from another mailing list that the QA team are right in the middle of one of their special bug-hunting sessions. So it's an especially good time to join in there. A lot of new people join in for those so even just lurking on their mailing list can be a good way of learning how to join in, if you are a bit shy of daring to ask ;) Also it's a good time to ask stupid questions aimed at trying to figure out how to join in because other people lurking there will probably be relieved you asked and it gives some other new people a chance to help (ie maybe good for morale). At the very least it's a good time for the rest of us to at least test-drive the new branch Regards from Tom :) On 22 November 2014 at 15:47, V Stuart Foote vstuart.fo...@utsa.edu wrote: Oops, correct that last... s/rc2/alpha2/ we're not that far along with the 4.4 branch. -- View this message in context: http://nabble.documentfoundation.org/Comments-on-pdf-file-size-in-4-4-alpha-and-a-new-bug-tp4129842p4129893.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] mongodb and base
(Kind of wandering off the mailing list's topic, but...) On Sat, 22 Nov 2014 21:25:17 -0500 Eric S. Johansson e...@esjworks.com wrote: [snip] No problem, I appreciate the input. Unfortunately, my experience with SQL over the past 30 years has taught me to stay away from SQL as far as absolutely possible. It's kind of sounding like your issue isn't SQL, per se, but the entire relational model. It is true that, for some applications, the relational model does not work well. [snip] Usually, the group of people I work with leave the database to the very last and isolated. We do that so the rest of the application is not contaminated by SQL isms and we have a nailed down definition of the schema. *That*, IMO, when you know your backend store is going to be on an RDBMS, is just asking for grief. It's been years since I studied theory on software system design methodologies, but, last I did, it was coming into vogue to first design *all* of the data elements, and their transformations, then design the software around that. My last couple major projects I used such systems and they worked quite well. We don't have hard numbers yet but with MongoDB, we are not getting any of the chaos and heartache that SQL delivers on a regular basis. I just took a quick look at MongoDB. Looks interesting. But, just as being locked into knowing only the RDBMS solution results in the if all you have is a hammer syndrome: I'd argue that one could not *possibly* deliver the best solutions for all scenarios approaching them from the perspective that RDBMS' are to be avoided to the extent possible, and then left to the last minute. It's like the big data question. There are really, really large datasets that aren't well-suited to common RDBMS', either. At the opposite end: Tiny databases in embedded systems. Then there are directories (read-heavy, light on write activity). I really do wish I SQL would go the way of COBOL. I would never say impossible, but it seems unlikely in the extreme. SQL is simply a human-oriented way of interfacing with an RDBMS, and RDBMS' are well-suited to any number of solutions requiring datastores. I'm glad you raised this issue, however. I had not been aware of MongoDB. It deserves a close look. Thanks! Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Comments on pdf file size in 4.4 alpha; and a new bug?
Tom, I think this is really well explained. I've been professionally involved in defect reporting for years, and the problems seem to be the same in all organisations. Problems in defect reporting: 1- Qualification of type (A bug is unexpected behaviour which does not comply to the requirements; An enhancement request is new development which changes both requirements and code) 2- Severity (How serious is the bug/enhancement request from users perspective) 3- Priority (What is the priority with respect to other bug/enhancement reports) Neither of these I see in out bugzilla defect reporting... There should be a moderator (not a developer) to map out the priority. One can set out rather strict rules for this, think about amount of complaints for the same, file corruption, system crash, etc. If we would go along these lines we might get away with the tension between (expert-) users and developers. But again, good effort here to get things ironed out, Thanks Tom, Rob. Op 23 nov. 2014, om 04:23 heeft som het volgende geschreven: On Saturday, 22 November 2014 8:39 PM, Tom Davies tomc...@gmail.com wrote: Hi :) I think there might be a few different things going on there. Firstly i have no idea how the devs think or work. Clearly they think very differently from most users. What seems obvious and makes sense to us is clearly 'wrong'. To me, i'd agree with you, that if it's annoying in one branch and still exists in the next then it's likely to be annoying in that branch too. Clearly the devs don't think like that at all. Trying to argue the point is likely to get you in trouble here. It's one of the reasons i am under moderation or even chucked off mailing lists here. What normal users, like us, tend to think of as bugs or stability issues is often technically called something else. So far i can only think of 5 but i'm sure there are more. The most frequent type of 'bug' reported by normal users is often really a broken feature. That is very different from what the devs would call a bug, as far as i can make out. It's certainly NOT a stability issue. Very few bugs are anything to do with stability. So when something is broken we have to try to figure out whether the devs would call it; 1. something that behaves differently from certain other programs (but the LO way might well be better) 2. something behaving weirdly 3. something that changed behaviour 4. a broken feature/thing 5. a bug or 6. a bug causing a stability issue Sometimes there is no practical difference between 1 and 2 or it might be just a difference of opinion, ie immensely long and argumentative threads. We rarely discuss items such as 3 because we mostly just adapt or new people are unaware it used to be any different. Sometimes it's intriguing or interesting. Occasionally a change in behaviour only happens to 1 person and indicates weird things going wrong which all gets fixed by renaming the User Profile. More usually it's a positive thing that a few people find annoying but most people either don't care or find it an improvement. (like when some obscure graphs got smoothed out in a better way that gave better results and looked nicer (i think in 3.4.0)). Mostly what we get here is 4. A long running feature/thing suddenly stops working in a new branch. We try renaming the User Profile jic it's that (despite it seeming really unlikely) and post a bug-report only to find we gets loads of aggro from devs telling us to fix it ourselves or that individuals should pay to get it fixed. Sometimes it gets all bitter and unnecessary blaming individuals who are all trying to do a good job but that sometimes leads to unexpected complications out in the wild. Maybe we should post these as feature requests and pretend that it's new in order to avoid hurting anyone's feelings? Very occasionally we get a real 5 but it's actually quite unusual, and quite difficult to spot since everything else is also called by the same name by most normal users. We seem to get a real 6 much more often than a real 5 but then it turns out to be a Java or other 3rd party issue. We still quite often help fix it. I think one time it turned out to be a wobbly graphics card and another time a defective fan but usually it's just a case or trying a different version of either Java or LibreOffice. Unfortunately pretty much all those things can only be reported by posting a bug-report. Feature requests use the bug-reporting systems. In that system one of the drop-downs has an option labelled feature request. We can often help with most of them, especially 1 and 2 and even 6 but the only route to escalate problems is to post a bug-report. I tried liaising with other mailing lists to see if they could help with other issues but it earned me a bad reputation so i wouldn't advise it! Now is the ideal time to take the 4.4.0 for a test-drive. It's
[libreoffice-users] Re: Comments on pdf file size in 4.4 alpha; and a new bug?
@Rob, *, Rob Jasper wrote I think this is really well explained. I've been professionally involved in defect reporting for years, and the problems seem to be the same in all organisations. Problems in defect reporting: 1- Qualification of type (A bug is unexpected behaviour which does not comply to the requirements; An enhancement request is new development which changes both requirements and code) 2- Severity (How serious is the bug/enhancement request from users perspective) 3- Priority (What is the priority with respect to other bug/enhancement reports) Neither of these I see in out bugzilla defect reporting... There should be a moderator (not a developer) to map out the priority. One can set out rather strict rules for this, think about amount of complaints for the same, file corruption, system crash, etc. If we would go along these lines we might get away with the tension between (expert-) users and developers. But again, good effort here to get things ironed out, Thanks Tom, Rob. Actually, the LibreOffice project is rather well organized in this regard--please review the QA Wiki here: https://wiki.documentfoundation.org/QA QA is a distinct entity to Development--and while there is certainly some cross over, the developers are not moderators of the process. That falls to the Engineering Steering Committee with input from the entire community--QA team, UX and Design team, Documentation team, Localization/Internationalization team, Marketing team and the occasional needs of TDF board. So, always room to participate. Please start as Tom suggested by loading a current build of the 4.4.0 build, or a daily Tinderbox of master and test there. We can always use additional help with the QA process--get a login on our FDO hosted Bugzilla instance https://bugs.freedesktop.org/ and dive in, plenty of triage work to go around. Regards, Stuart -- View this message in context: http://nabble.documentfoundation.org/Comments-on-pdf-file-size-in-4-4-alpha-and-a-new-bug-tp4129842p4130104.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-users] Re: Comments on pdf file size in 4.4 alpha; and a new bug?
Am 23.11.2014 um 18:14 schrieb Rob Jasper: Tom, I think this is really well explained. I've been professionally involved in defect reporting for years, and the problems seem to be the same in all organisations. Problems in defect reporting: 1- Qualification of type (A bug is unexpected behaviour which does not comply to the requirements; An enhancement request is new development which changes both requirements and code) Unexpected behaviour is a bug when it was unexpected by the programmer. In the eyes of a user, some program may do weird and unexpected things but if it does the exact weird things that it has been programmed for then there is no bug. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Re: Comments on pdf file size in 4.4 alpha; and a new bug?
On Sun, 23 Nov 2014 23:30:43 +0100 Andreas Säger ville...@t-online.de wrote: Am 23.11.2014 um 18:14 schrieb Rob Jasper: Problems in defect reporting: 1- Qualification of type (A bug is unexpected behaviour which does not comply to the requirements; An enhancement request is new development which changes both requirements and code) Unexpected behaviour is a bug when it was unexpected by the programmer. In the eyes of a user, some program may do weird and unexpected things but if it does the exact weird things that it has been programmed for then there is no bug. Tell that to my clients :) I can assure you that if a program, while acting exactly as I intended it to when I coded it, does not do what the spec requires it to, then the client calls it a bug, and expects me to fix it. And rightly so. Of course, with LO the situation is a little different, due to the lack of a formal client and thus a formal requirements document. If a feature doesn't work as expected by the users, but does work as expected by the developer who implemented it, then perhaps calling it a bug is incorrect. Instead it is merely a feature that was implemented in a manner that proved not to be useful. It's also not an enhancement request, really. It all comes down to what is taken as the requirement of the feature. If the feature started life as an enhancement request, then that, if it is complete in this regard, will be the requirement. If I, as a user, were logging a ticket for a feature that didn't work the way I expected, and there was no original enhancement request or clear feature specification, my choice of ticket type would depend on my understanding of the feature. If I understood where the developer was coming from, but had a different opinion of how the feature should work, or desired an alternative implementation alongside the existing one, I would log the ticket as an enhancement request. But if I felt the feature should work differently, and working the way the developer had coded it was incorrect in my opinion, then I would log it as a bug. It would be up to those in charge of such matters to determine which way they felt was correct, and to either fix the bug, or close the ticket. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] mongodb and base
On 23/11/14 02:25, Eric S. Johansson wrote: Given the nature the information and their standing as a title authority, I'm making a guess here, but that sentence implies that the firm not only has to have current boundaries, but also former boundaries of the property in question, and be able to explain why those boundaries appear to have, and in some cases really did change. The primary change is our building together more detailed information about properties that we had in the past and do it more accurately. I don't know what country you are in. Several decades ago, I had the experience of being tasked with finding the current, legal boundaries of some property the company I worked for wanted to foreclose on. The boundary line, according to the title deed was Westward from Mama's grave to the three elm trees. John's property begins at the first tree. Jane's property begins at the third tree. Needless to say, no survey map, or government database said where Mama's grave was. Equally helpful was the lack of elm trees on any of the properties in question. I can imagine the issues a Title company would have, to prove to a hostile jury that the property being foreclosed upon, and the property described in the title deed are the same property. Instead of foreclosing on the property, we sold that mortgage to a sucker. I think they're also changing legal requirements on titles with regards to title searches and their validity. Fortunately, those changes are very very slow. Doesn't matter how slow they are. When implemented, the relevant data has to be added to every parcel, and sub-parcel. (Here's looking at a parcel of land that the Attorney General of the State of Arizona, and the Attorney General of the State of Utah told a judge that he has had ten years to determine who originally owned what, and where it was located, and that that should be enough time to determine who owned what, and where it was located, and when they owned it, and he needs to finish that job yesterday.(In all fairness to the judge, before that property fell into the courts, the organization that claimed to own it, probably did own it, even if there are no official records to show how they acquired it, or when they acquired it, or what they acquired.)) I know enough about their world there to consider walking away from this contract because of the internal bickering. I probably just described the best reason for walking away. :-) Or the best reason to add a couple of more zeros just to the left of the decimal point. I was trying to close out the matrix and see if I could use beast to replace the report and data entry tools now lost to Informix. Using Base and MongoDB as an Informix clone will require writing, and supporting several extensions for Base. I really do wish I SQL would go the way of COBOL. Intrinsically, there is nothing wrong with either COBOL or SQL. The problem is that people who use those tools tend to suffer from the computing equivalent of extreme monolingualism, thereby demonstrating the validity of the Sapir-Whorf hypothesis. jonathon * English - detected * English * English javascript:void(0); -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
