从头开始创建一个图形库 - 页 2

 
Алексей Барбашин:

我相信这不值得从头做起。

非常聪明的人花费了大量的时间和知识来制作相同的标准库Anatoli库

人们已经投入了时间和知识,不利用它是愚蠢的。

从我们的角度来看,我们应该在两者中取其精华,建立一个新的。

我们需要从别人的错误中学习。我们将自己制作)。

只为!

 
图书馆的最终目标并不明确。
它应该解决或扩大其他图书馆的哪些缺点?或者它应该成为一个根本性的新工具?它应该是面向GUI还是面向用户的东西?
例如,我的iCanvas库是CCanvas库的逻辑延续,目的是提高用户图形的可用性,编码时代码更短、更直观,通过避免异步函数提高速度,链接到价格-时间坐标 系统,而不仅仅是XU屏幕坐标。
 
Nikolai Semko:
图书馆的最终目标并不明确。

而据我所知,这是所有图形库 的一个共同问题。

论坛上提供的所有项目都要解决两个问题中的一个:要么增加用户的收入,要么提高获得相同收入的效率。

我不记得有一个项目的作者费力地展示例子,说明如何解决这些问题之一。

最引人注目的例子,我记得是在 "画布很酷 "的主题中,呈现的是简单的令人着迷的美丽图形......。然而,它是如何增加用户(至少是作者)的收入的,或者是如何增加获得收入的效率的--我一直不明白。

阿纳托利的图书馆也是如此。结构很好,考虑周全,但...我相信即使是作者本人也不会使用这个库的所有功能。至于用户,我认为我们可以忘记他们。

另一个例子是彼得-科诺夫的项目。对于那些不能(不想)理解OOP的人来说,这是一个具有良好功能的工作解决方案,但是......同样--没有一个例子显示创收效率的提高。


在我看来,这些项目大多是为了培养作者的自负,更有必要。一般来说,这是一个必要的事情。但是,人们不应期待任何 "最终目标"。这就像期望我的TS联盟(这只是各种简单专家的集合)能够监测、盈利、圣杯......尽管它只是各种TS原则在不同符号上发挥作用的一个指标。

 
Georgiy Merts:

而据我所知,这是所有图形库的一个共同问题。

论坛上提供的所有项目都要解决两个问题中的一个:要么增加用户的收入,要么提高获得相同收入的效率。

我不记得至少有一个项目的作者费力地展示了例子,说明如何解决这些任务之一。

事实上,这是程序员论坛的一个部分.....你不应该在这里寻找经济意义上的东西)))。我自己更喜欢在这个论坛上单独解决这些问题。

尼古拉-森科
图书馆的最终目标并不明确。
它应该解决其他图书馆的哪些缺点或扩大可能性?或者它应该成为一个根本性的新工具?它应该是面向GUI还是面向用户的东西?
例如,我的iCanvas库是CCanvas库的逻辑延续,目的是提高自定义图形的可用性,在编码时使代码更短、更直观,通过避免异步函数提高速度,链接到价格-时间坐标 系统,而不仅仅是XU屏幕坐标。

我从你的库开始,感谢你,然后我对它进行了一些改进,然后是一些)))),最后改变了一切,包括重写了行的函数,也从Kanvas的源码中获得了宽行函数,删除了假函数,在事件上放了存根。还没有完全放弃结构W,虽然那里也没有什么东西了。我在其他元素中加入了通过二进制搜索计算左边和右边的条形,还加入了二进制搜索本身,可以选择更大或更小的值。还增加了从任何类型的数组(时间序列/普通)建立的能力,并得出结论,有必要改变构造))))))。

 

我已经走了一圈。

我理解这种等级制度。

我必须再做一次控制,但仍有一些坐标我想单独放。我想把它们放在一个圈子里。我认为kotrol将从坐标出发,所以它将更真实,并大大简化了系统。当然,我的论点可能是错误的--但到目前为止,这似乎是一个天真的解决方案。

而kotrol--这只不过是风格的一个基本要素--理论上应该在坐标之后。

逻辑 - 我们可以有一个没有样式的元素,但不能没有坐标的元素

 
Alexandr Andreev:

这实际上是程序员论坛的一个部分 .....你不应该在这里寻找经济意义上的东西)))我自己更喜欢在这个论坛上单独处理这些问题。

非常有趣。

旁边有一个主题,有激烈的争论,"没有人会免费工作"--你说,"不值得寻找经济意义 "吗?

 
Georgiy Merts:

非常有趣。

在 "没有人会免费工作 "的话题旁边,你说 "不要寻找经济意义"?

我甚至没有宣称自己是图书馆的作者,我收到....。更不用说它的财务部分了。

我只是想知道应该如何做--正确地做。

如果有小的需要,你甚至可以在废品堆中收集代码。

虽然理想情况下我想做一些这个正确的迷你版本。为了实现最小的代码和最大的实用性。

 
Nikolai Semko:
图书馆的最终目标并不明确
它应该解决或扩大其他图书馆的哪些不足之处?或者它应该成为一个根本性的新工具?它应该是面向GUI还是面向用户的东西?
例如,我的iCanvas库是CCanvas库的逻辑延续,目的是提高自定义图形的可用性,编码时代码更短、更直观,通过避免异步函数提高速度,并链接到价格-时间坐标 系统,而不仅仅是XU屏幕坐标。

尼古拉,欢迎。

最终目标是尝试解决目前已经存在的工具的缺点。

我想最有可能的是继续开发标准库,以提高其与项目连接的便利性,并改进图形组件,离开图表对象并转移到画布。

但总的来说,我们不要猜测结果会是什么。

 
Алексей Барбашин:

尼古拉,欢迎。

最终目标是尝试解决目前已经存在的工具的缺点。

我想,最有可能的是继续开发标准库,以提高其与项目连接的便利性,并改进图形组件,留下图表对象和过渡到画布。

但总的来说,我们不要为将会发生什么而困惑。

简而言之,关于工程:

如果你有一种冲动,想通过重新设计来改善一些 "A",你应该明确它的关键缺陷。只要列出它们,并解释为什么在 "A "的进化发展过程中不可能消除它们。

另一方面,没有人禁止它。如果你喜欢写代码,就写吧...你将重写 "A",但以你自己的方式,但它将是新的。

 
Alexandr Andreev:

我已经走了一圈。

我理解这种等级制度。

我必须再做一次控制,但仍有一些坐标我想单独放。我想把它们放在一个圈子里。我认为kotrol将从坐标出发,所以它将更真实,并大大简化了系统。 当然,我的论点可能是错误的--但到目前为止,这似乎是一个天真的解决方案。

而kotrol--这只不过是风格的一个基本要素--理论上应该在坐标之后。

逻辑 - 我们可以有一个没有样式的元素,但不能没有坐标。

你甚至不需要争论这个问题,这是真的))))。

风格、主题--如果你最初设想要增加这些东西的话,以后都可以把它们拧在一起。事实上,所有这些都应该发生在一个基本控件中,因此,功能的增加也将在这个类别中进行。

关于坐标,我看到有两种类型--绝对坐标,它是相对于图表计算的,而本地坐标,它是相对于父本计算的。

例如,如果一个表单被渲染,它在图表中的位置是由绝对坐标处理的。 如果一个按钮被放置在一个表单中,它必须相对于放置它的容器定位,即相对于表单定位。

当收到鼠标移动事件时,我们在处理程序中得到光标点相对于图表的绝对坐标。当验证光标是否击中表单或任何一个元素时,我们需要比较光标的绝对坐标和元素的当前位置,同时考虑到它的定位。也就是说,对于一个表单来说,它只是与它的当前坐标和尺寸进行比较,但对于一个按钮来说,它将计算出按钮在坐标系中的绝对位置。也就是说,用于比较的X坐标将被计算如下X = (Parent==null)?X():(X()+Parent.X()), 其中X()是一个类函数,返回项目的X位置。然而,对父类本身存在的检查可以在这个函数本身中进行。结果是,如果一个项目有一个父项,那么坐标将作为父项的坐标与它自己 在父项中的坐标 相加而返回。事实上,嵌套元素的数量可以是任意的,而且每个元素都是相对于它所在的元素定位的,而不是相对于图形定位的,所以绝对坐标可以被递归计算。

原因: