리브로 오피스 실망이네요.

emptynote의 이미지

맘 먹고 리브로 오피스로 문서 작성을 하고자 했는데

버그때문에 속상하네요.

그룹화 해서 제목 크기 변경햇을뿐인데 그룹내 도형에 종속된 문자 박스는

도형에 종속되지 않고 엉뚱한 곳에 있네요.

힘들게 문서 작성한 내용이 날라간거라 맘이 아프네요.

File attachments: 
세벌의 이미지

https://bugs.documentfoundation.org/ 에 버그를 알려주셔요.

투정하듯이 글을 쓰면 효과가 좋나요?

emptynote의 이미지

불평 불만 없으면 발전도 없는겁니다.

버그 보고는 했지만 영어가 아닌 한글로 보고를 했습니다.

왜? 버그에 화가나서요.

세벌님 개밥 먹지도 않으면서

"투정하듯이 글을 쓰면 효과가 좋나요" 라는 댓글만 주구장창 달면

뭐 살림살이 나아지십니까?

개밥이라고 당신이 먹지도 않는 것

직접 먹어보고 보거

버그 보고한 사람한테 이 무슨 예의없는 짓입니까?

버그 보고 참고 주소 : https://bugs.documentfoundation.org/show_bug.cgi?id=116368

세벌의 이미지

버고 보고 하셨군요.
그 버그 보고 한 글에 답글이 달렸네요.
English only, please.
라고요.

영어 어렵다면, 님께서 우리말로 작성하신 버그 보고를 구글 번역 돌려서 영어로 올리는 게 좋겠습니다.

emptynote의 이미지

역시나 보고 싶은것만 보는 습관은 아직도 여전하시군요.

스샷 올렸고 그 스샷 속에 모든것이 있습니다.

그 버그는 구현하기 매우 쉬운 버그입니다.

이런 문제는 테스트 자동화로 문제를 미리 검출해서 제거 했어야 합니다.

스샷 보고 문제가 무엇인지 즉각적으로 인지를 했다면 혹여 개선할 희망을 가질 수 있겠지만

영문이 아니라서 무슨 문제인지 모르겠다면 그냥 망하도록 두어야지요.

세벌의 이미지

싫건 좋건 현실은 영어가 전세계에서 통하는 언어가 되어있죠.
한글을 모르는 사람들이
스샷 보고 문제가 무엇인지 즉각적으로 인지를 할 수 있을까요?

emptynote의 이미지

세벌님 당신에겐 공감 능력이 있으십니까?

예전에 당신과 이 문제로 싸웠던 당사자입니다.

사과까지 했지만 악어의 눈물 그 이상도 이하도 아니군요.

세벌님이 운영하는 세벌 사랑넷에서 저랑 논쟁한 글은 부끄러운지 금세 지워 버리고

세벌 사랑 사이트에서는 우분투에서 세벌 논쟁이라고 치장을 하시더군요.

왠만하면 그냥 그러려니 살고 싶은데 이 문제 다시 재 점화를 원하신다면 그리 해 드리겠습니다.

세벌의 이미지

님께서는 공감을 바랬는데 제가 그걸 몰랐군요.
LibreOffice 문제가 아니었군요.

제가 동문서답을 한 거였군요...

emptynote의 이미지

여전히 공감능력 없이 소통하시려 하면 누가 응답이 있겠습니까?

안타까운 마음에 말을 해 주어도 못 알아 듣는데

가족도 아니고 누가 당신을 품어 줄까요.

세벌의 이미지

https://forum.ubuntu-kr.org/viewtopic.php?f=4&t=29892
emptynote 님과 다른 분일지도 모르겠습니다만...
그대를 품어줄 사람은 있나요?

emptynote의 이미지

잘 지내니 걱정 마세요.

세벌님 나는 그림으로 생각한다 템플 그랜딘
이라는 분계시는데 그분 이해해서 답하는것이 아니라
외워서 답변 하는 경우도 있다하십니다.

세벌님도 그분의 그런 행동 참고하시면
좀더 친구를 사귀는데 도움이 되실것 같습니다

세벌의 이미지

이 글타래도 그렇고.
https://forum.ubuntu-kr.org/viewtopic.php?f=4&t=29892
에도 다른 사람의 답글이 없는 것을 보면.

세벌의 이미지

?
https://forum.ubuntu-kr.org/viewtopic.php?f=4&t=29892 페이지를 찾을 수가 없네요. 원 글 쓰신 분이 지운 건지? 관리자님이 지운 건지? 모르겠지만...

emptynote의 이미지

과거 버전에서는 레이아웃이 조금 깨져도 사각형 박스에서 추가한 글자 상자라는 종속성은 그래도 유지를 했는데

최신 버전에서는 종속성이 사라져 사각형 박스랑 상관없이 추가된 글상자일뿐이네요.

이 말은 리브레 오피스 개발팀이 개밥 먹지 않고 개발만 한다는 뜻이고

간단히 말하면 망조이기에 참담함을 금할 수없네요.

emptynote의 이미지

리브레 오피스팀은 지금이라도 테스트 자동화를 안했다면 구축해야 합니다.

여기 TDD 로 개발한 오픈 소스로 mybatis-dynamic-sql 가 있는데 그 자신감이 하늘을 찌릅니다.

겸손이라는것을 모르기에 어처구니가 없지만 그래도 시사하는 봐가 있습니다.

오픈 소스도 이제 다람쥐 체 바퀴 돌듯이 버그 보고 오면 고치겠다는 안일한 생각을 타파할 때가 되었습니다.

이제까지는 소스 코드 제공에 감사한 마음을 갖고 덮썩 받아 먹는데 급급했지만

더 이상 테스트 하지 않은 코드에 대해서 NO 라고 말해야 할 시기가 왔다 생각합니다.

------------ 부분 인용
TDD 자신감에 하늘 높은줄 모르는 콧데를 가진 참고 주소 : http://www.mybatis.org/mybatis-dynamic-sql/docs/codingStandards.html

We are committed to clean code. This means:
Small methods - less than 5 lines is good, 1 line is ideal
Small classes - less than 100 lines is good, less than 50 lines is ideal
Use descriptive names
Comments are a last resort - don’t comment bad code, refactor it
No nested control structures - ideal cyclomatic complexity of a function is 1
Maintain 100% test coverage
Run SonarQube analysis - do not add any technical debt, bugs, code smells, etc.

세벌의 이미지

https://ask.libreoffice.org/ko/questions/ 에서 얘기해 보는 건 어떤가요?

Necromancer의 이미지

그나마 지금은 많이 개선 된겁니다. 그정도면 자잘한거죠.
초기 오픈오피스 시절에는 저장시에 text 일부가 날라간다든가(한두문장이 아니라 페이지 단위로 날라갔습니다. 제가 실제로 당해봤음) 하는 일이 있었습니다.

아무래도 취미로 하는거다 보니까 이런 부분에서는 약할 수밖에 없지요.

여러 개발 방법론을 적용해서 이런것들을 막을 시스템이 필요하다고 봅니다.

큰 S/W일수록 버그 가능성이 커지고, 오피스는 그 하나가 엄청나게 큰 S/W입니다. 소스빌드할때 빌드타임만 봐도 ㅎㄷㄷ.
(어떤분은 KDE가 크다고 하시는데 KDE는 나뉘어 있어서 리브레오피스보다는 버그 가능성이 덜한 편입니다.)

Written By the Black Knight of Destruction

emptynote의 이미지

예 큰 S/W 라는 말씀에 동의합니다.

그래도 리눅스 부심에 기대치를 낮출 수 가 없습니다. 이점은 이해 바랍니다.