다른 라이브러리의 어떤 단점을 해결하거나 개선해야 합니까? 아니면 근본적으로 새로운 도구가 되어야 합니까? GUI 지향 또는 사용자 그래픽 지향이어야 합니까?
예를 들어, 내 iCanvas 라이브러리는 사용자 지정 그래픽의 사용성 향상, 코딩 시 더 짧고 직관적인 코드, 비동기 기능의 사용을 피하여 작업 속도 증가, 가격 에 대한 바인딩을 목표로 CCanvas 라이브러리의 논리적 확장이었습니다. - XY 화면 좌표뿐만 아니라 시간 좌표 시스템.
그리고 이것은 내가 어떻게 보든지 상관없이 모든 그래픽 라이브러리 의 공통적인 문제입니다.
포럼에서 제안된 모든 프로젝트는 사용자의 수입을 늘리거나 동일한 수입을 얻는 효율성을 높이는 두 가지 문제 중 하나를 해결해야 합니다.
적어도 한 명의 프로젝트 작성자가 이러한 작업 중 하나의 솔루션을 설명하는 예를 보여주기 위해 애썼다는 것을 기억하지 못합니다.
가장 눈에 띄는 예는 "Canvas is cool"이라는 주제에서 - 단순히 요염할 정도로 아름다운 그래픽이 제공되었지만 ... 사용자(적어도 저자)의 수입을 어떻게 증가시켰는지, 또는 어떻게 효율성을 증가시켰는지 기억합니다. 그것을 받고 - 나는 여전히 이해하지 못했습니다.
Anatoly의 도서관도 마찬가지입니다. 훌륭한 구조, 좋은 생각, 하지만... 저자 자신도 이 라이브러리의 모든 가능성과는 거리가 멀다고 확신합니다. 사용자를 위해 - 기억이 안 나는 것 같아요.
또 다른 예는 Peter Konov의 프로젝트입니다. OOP를 이해할 수 없는(원하지 않는) 사람들에게는 좋은 기회가 있는 꽤 효과적인 솔루션이지만 ... 다시 - 소득 창출 효율성의 증가를 보여주는 단일 예는 아닙니다.
제 생각에는 이러한 프로젝트의 대부분은 저자의 CSF를 육성하기 위해 더 필요한 것 같습니다. 일반적으로 필요한 것. 그러나 동시에 "최종 목표"를 기다릴 필요는 없습니다. 내 TS 리그(단순한 모든 종류의 단순한 전문가 집합) 모니터링, 이익, Grail에서 기대하는 것과 같습니다. 비록 다른 TS 원칙이 다른 기호에서 어떻게 작동하는지를 나타내는 지표일 뿐입니다.
포럼에서 제안된 모든 프로젝트는 사용자의 수입을 늘리거나 동일한 수입을 얻는 효율성을 높이는 두 가지 문제 중 하나를 해결해야 합니다.
적어도 한 명의 프로젝트 작성자가 이러한 작업 중 하나의 솔루션을 설명하는 예를 보여주기 위해 애썼다는 것을 기억하지 못합니다.
일반적으로 이것은 프로그래머 포럼의 섹션입니다 ..... 여기에서 재정적 감각을 찾지 않아야합니다.))) 나는이 포럼과 별도로 이러한 문제를 해결하는 것을 선호합니다.
니콜라이 셈코 : 도서관의 궁극적인 목표는 명확하지 않습니다.
다른 라이브러리의 어떤 단점을 해결하거나 개선해야 합니까? 아니면 근본적으로 새로운 도구가 되어야 합니까? GUI 지향 또는 사용자 그래픽 지향이어야 합니까?
예를 들어, 내 iCanvas 라이브러리는 사용자 지정 그래픽의 사용성 향상, 코딩 시 더 짧고 직관적인 코드, 비동기 기능의 사용을 피하여 작업 속도 증가, 가격 에 대한 바인딩을 목표로 CCanvas 라이브러리의 논리적 확장이었습니다. - XY 화면 좌표뿐만 아니라 시간 좌표계.
나는 당신의 라이브러리로 시작하여 감사합니다. 그런 다음 조금 빗질 한 다음 다시 빗질했습니다. , 이벤트에 스텁을 넣습니다. W 구조에서 아직 완전히 사라지지는 않았지만 거기에도 약간 남아 있습니다. 타사 요소 간의 이진 검색을 통해 왼쪽 및 오른쪽에서 각각 막대 계산을 추가했으며 더 크거나 작은 값을 선택할 수 있는 기능과 함께 이진 검색 자체를 양방향으로 추가했습니다. 나는 또한 모든 종류의 배열에서 빌드하는 기능을 추가했습니다(시계열/일반) 그리고 디자인을 변경해야 한다는 결론에 도달했습니다))))))
다시 제어. 동일하게 내가 별도로 꺼내고 싶은 좌표가 있다는 것이 밝혀졌습니다. 왜냐하면 상호 작용의 주요 부분은 원을 기반으로 합니다. 제어가 좌표에서 이동하므로 더 정확하고 시스템을 크게 단순화할 것이라고 생각합니다. 물론 내 주장이 틀릴 수도 있지만 지금까지는 순진한 결정처럼 보입니다.
다른 라이브러리의 어떤 단점을 해결하거나 개선해야 합니까? 아니면 근본적으로 새로운 도구가 되어야 할까요? GUI 지향 또는 사용자 그래픽 지향이어야 합니까?
예를 들어, 내 iCanvas 라이브러리는 사용자 지정 그래픽의 사용성 향상, 코딩 시 더 짧고 직관적인 코드, 비동기 기능의 사용을 피하여 작업 속도 증가, 가격 에 대한 바인딩을 목표로 CCanvas 라이브러리의 논리적 확장이었습니다. - XY 화면 좌표뿐만 아니라 시간 좌표 시스템.
니콜라스, 안녕.
궁극적인 목표는 현재 이미 생성된 도구의 단점을 제거하는 것입니다.
이것은 프로젝트에 연결하는 편의성을 높이고 그래픽 구성 요소 자체를 개선하여 차트 개체에서 벗어나 캔버스로 전환하기 위한 표준 라이브러리 개발의 연속이 될 가능성이 가장 높습니다.
다시 제어. 동일하게 내가 별도로 꺼내고 싶은 좌표가 있다는 것이 밝혀졌습니다. 왜냐하면 상호 작용의 주요 부분은 원을 기반으로 합니다. 제어가 좌표에서 이동하므로 더 정확하고 시스템을 크게 단순화할 것이라고 생각합니다. 물론 내 주장이 틀릴 수도 있지만 지금까지는 순진한 결정처럼 보입니다.
그리고 제어는 스타일의 기본 요소일 뿐입니다. 이론상 좌표 뒤에 있어야 합니다.
논리 - 스타일이 없는 요소는 가질 수 있지만 좌표는 가질 수 없습니다.
이것에 대해 논쟁 할 필요가 없습니다. 그렇습니다)))
스타일, 테마 - 이러한 추가가 처음에 예상되는 경우 이 모든 것이 나중에 추가될 수 있습니다. 사실 이 모든 것은 기본 컨트롤에서 이루어져야 하므로 이 클래스의 기능도 향상됩니다.
좌표와 관련하여: 여기에 두 가지 유형의 좌표가 표시됩니다. 그래프를 기준으로 계산되는 절대 좌표와 상위 좌표를 기준으로 계산되는 로컬 좌표입니다.
예를 들어, 양식이 만들어지면 차트에서의 배치는 절대 좌표를 통해 처리되고 버튼이 양식에 배치되면 해당 위치는 배치되는 컨테이너를 기준으로 지정되어야 합니다. , 형식을 기준으로 합니다.
마우스 이동 이벤트가 도착하면 핸들러의 차트를 기준으로 커서 지점의 절대 좌표를 얻습니다. 커서가 폼이나 요소에 닿았는지 확인할 때 위치를 고려하여 커서의 절대 좌표를 요소의 현재 위치와 비교할 필요가 있습니다. 즉, 양식의 경우 현재 좌표 및 크기와의 비교일 뿐이고 버튼의 경우 좌표계에서 버튼의 절대 위치 계산이 됩니다. 즉, 비교를 위한 X 좌표는 다음과 같이 계산됩니다. X = (Parent==null)?X():(X()+Parent.X()), 여기서 X()는 다음을 반환하는 클래스 함수입니다. 요소의 X 위치입니다. 그러나 이 함수 자체에서 부모의 존재 여부를 확인할 수 있습니다. 결과적으로 요소에 부모가 있는 경우 해당 좌표는 부모의 자체 좌표 와 부모의 좌표를 더한 값으로 반환됩니다. 실제로 중첩된 요소의 수는 임의적일 수 있으며 각 요소는 차트가 아닌 해당 요소가 위치한 요소를 기준으로 위치하므로 절대 좌표를 재귀적으로 계산할 수 있습니다.
나는 그것이 처음부터 가치가 없다고 확신합니다.
아주 똑똑한 사람들은 동일한 표준 라이브러리 나 Anatolia 라이브러리 를 만들기 위해 많은 시간과 지식을 투자했습니다.
사람들은 시간과 지식을 낭비했고 그것을 사용하지 않는 것은 어리석은 일입니다.
우리의 관점에서 두 가지 모두에서 최고를 취하고 새로운 것을 수집하면 됩니다.
다른 사람의 실수로부터 배워야 합니다. 우리는 우리 자신을 만들 것입니다 :)
전적으로 동의합니다!
도서관의 궁극적인 목표는 명확하지 않습니다.
그리고 이것은 내가 어떻게 보든지 상관없이 모든 그래픽 라이브러리 의 공통적인 문제입니다.
포럼에서 제안된 모든 프로젝트는 사용자의 수입을 늘리거나 동일한 수입을 얻는 효율성을 높이는 두 가지 문제 중 하나를 해결해야 합니다.
적어도 한 명의 프로젝트 작성자가 이러한 작업 중 하나의 솔루션을 설명하는 예를 보여주기 위해 애썼다는 것을 기억하지 못합니다.
가장 눈에 띄는 예는 "Canvas is cool"이라는 주제에서 - 단순히 요염할 정도로 아름다운 그래픽이 제공되었지만 ... 사용자(적어도 저자)의 수입을 어떻게 증가시켰는지, 또는 어떻게 효율성을 증가시켰는지 기억합니다. 그것을 받고 - 나는 여전히 이해하지 못했습니다.
Anatoly의 도서관도 마찬가지입니다. 훌륭한 구조, 좋은 생각, 하지만... 저자 자신도 이 라이브러리의 모든 가능성과는 거리가 멀다고 확신합니다. 사용자를 위해 - 기억이 안 나는 것 같아요.
또 다른 예는 Peter Konov의 프로젝트입니다. OOP를 이해할 수 없는(원하지 않는) 사람들에게는 좋은 기회가 있는 꽤 효과적인 솔루션이지만 ... 다시 - 소득 창출 효율성의 증가를 보여주는 단일 예는 아닙니다.
제 생각에는 이러한 프로젝트의 대부분은 저자의 CSF를 육성하기 위해 더 필요한 것 같습니다. 일반적으로 필요한 것. 그러나 동시에 "최종 목표"를 기다릴 필요는 없습니다. 내 TS 리그(단순한 모든 종류의 단순한 전문가 집합) 모니터링, 이익, Grail에서 기대하는 것과 같습니다. 비록 다른 TS 원칙이 다른 기호에서 어떻게 작동하는지를 나타내는 지표일 뿐입니다.
그리고 이것은 내가 어떻게 보이든 모든 그래픽 라이브러리의 공통적인 문제입니다.
포럼에서 제안된 모든 프로젝트는 사용자의 수입을 늘리거나 동일한 수입을 얻는 효율성을 높이는 두 가지 문제 중 하나를 해결해야 합니다.
적어도 한 명의 프로젝트 작성자가 이러한 작업 중 하나의 솔루션을 설명하는 예를 보여주기 위해 애썼다는 것을 기억하지 못합니다.
일반적으로 이것은 프로그래머 포럼의 섹션입니다 ..... 여기에서 재정적 감각을 찾지 않아야합니다.))) 나는이 포럼과 별도로 이러한 문제를 해결하는 것을 선호합니다.
도서관의 궁극적인 목표는 명확하지 않습니다.
나는 당신의 라이브러리로 시작하여 감사합니다. 그런 다음 조금 빗질 한 다음 다시 빗질했습니다. , 이벤트에 스텁을 넣습니다. W 구조에서 아직 완전히 사라지지는 않았지만 거기에도 약간 남아 있습니다. 타사 요소 간의 이진 검색을 통해 왼쪽 및 오른쪽에서 각각 막대 계산을 추가했으며 더 크거나 작은 값을 선택할 수 있는 기능과 함께 이진 검색 자체를 양방향으로 추가했습니다. 나는 또한 모든 종류의 배열에서 빌드하는 기능을 추가했습니다(시계열/일반) 그리고 디자인을 변경해야 한다는 결론에 도달했습니다))))))
나는 완전한 원을 얻었다
계층 구조로 모든 것이 명확합니다.
다시 제어. 동일하게 내가 별도로 꺼내고 싶은 좌표가 있다는 것이 밝혀졌습니다. 왜냐하면 상호 작용의 주요 부분은 원을 기반으로 합니다. 제어가 좌표에서 이동하므로 더 정확하고 시스템을 크게 단순화할 것이라고 생각합니다. 물론 내 주장이 틀릴 수도 있지만 지금까지는 순진한 결정처럼 보입니다.
그리고 제어는 스타일의 기본 요소일 뿐입니다. 이론상 좌표 뒤에 있어야 합니다.
논리 - 스타일이 없는 요소는 가질 수 있지만 좌표는 가질 수 없습니다.
일반적으로 이것은 프로그래머 포럼의 섹션입니다 ..... 여기에서 재정적 감각을 찾지 않아야합니다.))) 나는이 포럼과 별도로 이러한 문제를 해결하는 것을 선호합니다.
아주 재미있다.
근처에는 "아무도 공짜로 일하지 않는다" - "금전적인 면을 찾지 말라"는 화끈한 배틀이 벌어지고 있는 화제 ???
아주 재미있다.
근처에는 "아무도 공짜로 일하지 않는다" - "금전적인 면을 찾지 말라"는 화끈한 배틀이 벌어지고 있는 화제 ???
글쎄, 나는 결과 라이브러리의 저자 인 척하지도 않습니다 .... 재정적 구성 요소에 대해 무엇을 말할 수 있습니까?
어떻게 해야 하는지 알고 싶었을 뿐입니다.
작은 필요로 무릎에 코드를 수집할 수도 있습니다.
이상적으로는 사냥이 이 올바른 빌드의 일종의 미니 버전입니다. 그것은 최소한의 코드와 최대의 유용성입니다.
도서관의 궁극적인 목표는 명확하지 않습니다.
니콜라스, 안녕.
궁극적인 목표는 현재 이미 생성된 도구의 단점을 제거하는 것입니다.
이것은 프로젝트에 연결하는 편의성을 높이고 그래픽 구성 요소 자체를 개선하여 차트 개체에서 벗어나 캔버스로 전환하기 위한 표준 라이브러리 개발의 연속이 될 가능성이 가장 높습니다.
글쎄, 일반적으로 우리는 무슨 일이 일어날지 추측하지 않을 것입니다.
니콜라스, 안녕.
궁극적인 목표는 현재 이미 생성된 도구의 단점을 제거하는 것입니다.
이것은 프로젝트에 연결하는 편의성을 높이고 그래픽 구성 요소 자체를 개선하여 차트 개체에서 벗어나 캔버스로 전환하기 위한 표준 라이브러리 개발의 연속이 될 가능성이 가장 높습니다.
글쎄, 일반적으로 우리는 무슨 일이 일어날지 추측하지 않을 것입니다.
간략하게 엔지니어링에 대해:
재개발을 통해 일부 "A"를 개선하려는 충동이 있는 경우 치명적인 단점을 명시할 필요가 있습니다. 'A'의 진화적 발달 과정에서 불가피한 이유를 나열하고 설명하시오.
반면에 아무도 그것을 금지하지 않습니다. 나는 코드를 작성하고 작성하는 것을 좋아합니다 ... "A"를 다시 작성하지만 자신의 방식으로 새 것입니다
나는 완전한 원을 얻었다
계층 구조로 모든 것이 명확합니다.
다시 제어. 동일하게 내가 별도로 꺼내고 싶은 좌표가 있다는 것이 밝혀졌습니다. 왜냐하면 상호 작용의 주요 부분은 원을 기반으로 합니다. 제어가 좌표에서 이동하므로 더 정확하고 시스템을 크게 단순화할 것이라고 생각합니다. 물론 내 주장이 틀릴 수도 있지만 지금까지는 순진한 결정처럼 보입니다.
그리고 제어는 스타일의 기본 요소일 뿐입니다. 이론상 좌표 뒤에 있어야 합니다.
논리 - 스타일이 없는 요소는 가질 수 있지만 좌표는 가질 수 없습니다.
이것에 대해 논쟁 할 필요가 없습니다. 그렇습니다)))
스타일, 테마 - 이러한 추가가 처음에 예상되는 경우 이 모든 것이 나중에 추가될 수 있습니다. 사실 이 모든 것은 기본 컨트롤에서 이루어져야 하므로 이 클래스의 기능도 향상됩니다.
좌표와 관련하여: 여기에 두 가지 유형의 좌표가 표시됩니다. 그래프를 기준으로 계산되는 절대 좌표와 상위 좌표를 기준으로 계산되는 로컬 좌표입니다.
예를 들어, 양식이 만들어지면 차트에서의 배치는 절대 좌표를 통해 처리되고 버튼이 양식에 배치되면 해당 위치는 배치되는 컨테이너를 기준으로 지정되어야 합니다. , 형식을 기준으로 합니다.
마우스 이동 이벤트가 도착하면 핸들러의 차트를 기준으로 커서 지점의 절대 좌표를 얻습니다. 커서가 폼이나 요소에 닿았는지 확인할 때 위치를 고려하여 커서의 절대 좌표를 요소의 현재 위치와 비교할 필요가 있습니다. 즉, 양식의 경우 현재 좌표 및 크기와의 비교일 뿐이고 버튼의 경우 좌표계에서 버튼의 절대 위치 계산이 됩니다. 즉, 비교를 위한 X 좌표는 다음과 같이 계산됩니다. X = (Parent==null)?X():(X()+Parent.X()), 여기서 X()는 다음을 반환하는 클래스 함수입니다. 요소의 X 위치입니다. 그러나 이 함수 자체에서 부모의 존재 여부를 확인할 수 있습니다. 결과적으로 요소에 부모가 있는 경우 해당 좌표는 부모의 자체 좌표 와 부모의 좌표를 더한 값으로 반환됩니다. 실제로 중첩된 요소의 수는 임의적일 수 있으며 각 요소는 차트가 아닌 해당 요소가 위치한 요소를 기준으로 위치하므로 절대 좌표를 재귀적으로 계산할 수 있습니다.